Автентифікація

Auth.js

Open source бібліотека автентифікації для вебзастосунків (раніше NextAuth.js), з провайдерами OAuth і сесіями.

Що це

Auth.js починався як NextAuth.js для Next.js, а потім став фреймворконезалежним. Бібліотека живе у вашому застосунку, дані користувачів зберігаються у вашій базі через адаптери.

Є готові провайдери (Google, GitHub та десятки інших), вхід за email-посиланням, логін-паролем (credentials) та вбудована робота з сесіями: JWT-cookie або сесії в базі.

Це хороший вибір, якщо хочеться контролю та відсутності плати за користувача. Відповідальність за безпеку конфігурації лежить на вас.

Коли брати

  • Next.js або SvelteKit застосунок із входом через соціальні мережі.
  • Потрібен контроль над даними без окремого сервера ідентифікації.
  • Невеликі й середні проєкти з обмеженим бюджетом.

Коли не варто

  • Потрібні корпоративний SSO, SAML і керування організаціями з коробки: Auth0, Clerk, Keycloak.
  • Мобільні застосунки та сервіс-до-сервісу авторизація.

Ключові поняття

Provider
Конфігурація зовнішнього входу (Google, GitHub).
Adapter
Шар збереження користувачів і сесій у вашій базі.
Session strategy
JWT у cookie або запис сесії в базі.
Callbacks
Хуки jwt і session для додавання власних полів.

Приклад

Мінімальна конфігурація з GitHub-провайдером.

Питання на співбесіді

  1. 1. JWT чи сесії в базі?

    JWT-сесія не потребує звернення до бази на кожен запит, але складніше відкликається. Сесія в базі дає миттєве відкликання, але додає запит до сховища.

  2. 2. Для чого адаптери?

    Щоб зберігати користувачів, акаунти й сесії у вашій базі (Prisma, Drizzle та інші). Без адаптера доступна лише JWT-стратегія.

  3. 3. Чи безпечний провайдер credentials?

    Він працює, але ви самі відповідаєте за хешування паролів, обмеження спроб і скидання. Для більшості випадків краще соціальні провайдери чи email-посилання.

Логотипи належать їхнім власникам і використані лише для ідентифікації. Іконки: Simple Icons (CC0), Devicon (MIT).

Розділи платформи