Настройка Auth.js в Next.js: провайдеры, сессии и защита маршрутов

Проблема: аутентификация в Next.js без боли

Мы часто видим, как разработчики тратят недели на реализацию входа через соцсети, а потом сталкиваются с багами при гидратации или утечкой сессий. NextAuth.js (теперь Auth.js) решает это «из коробки» за 1–4 дня. В нашей практике — 30+ проектов с разными провайдерами, от Google до самописных. Делимся готовым решением, которое защитит ваше приложение и сэкономит бюджет. Современные приложения требуют надежной аутентификации: OAuth, email magic link, логин/пароль. Мы интегрируем Auth.js v5 с App Router и Edge Runtime, обеспечивая быстрый рендеринг и безопасность на всех этапах. В отличие от самописных решений, Auth.js предоставляет готовые провайдеры, автоматическую защиту от CSRF и управление сессиями через JWT или database sessions. Выбор стратегии зависит от нагрузки и требований — мы поможем определить оптимальный вариант. Итог: экономия времени в 2-3 раза и отсутствие головной боли с безопасностью.

Какие задачи решает NextAuth.js?

NextAuth.js покрывает три основные задачи: безопасность сессий, мультипровайдерность и гибрид SSR/CSR. Сессии могут быть JWT или database sessions с Prisma. Мультипровайдерность: Google, GitHub, email magic link, логин/пароль — всё в одном конфиге. Гибрид SSR/CSR: сессия доступна и на сервере, и на клиенте без лишних запросов. Каждый из этих аспектов мы настраиваем под конкретный проект, учитывая нагрузку и требования к безопасности.

Как настроить Auth.js v5?

Мы используем Auth.js v5 с App Router и Edge Runtime. Конфигурируем в auth.ts:

// auth.ts
import NextAuth from 'next-auth';
import Google from 'next-auth/providers/google';
import GitHub from 'next-auth/providers/github';
import Credentials from 'next-auth/providers/credentials';
import { PrismaAdapter } from '@auth/prisma-adapter';
import { prisma } from '@/lib/prisma';

export const { handlers, signIn, signOut, auth } = NextAuth({
  adapter: PrismaAdapter(prisma),
  providers: [
    Google({ clientId: process.env.AUTH_GOOGLE_ID!, clientSecret: process.env.AUTH_GOOGLE_SECRET! }),
    GitHub({ clientId: process.env.AUTH_GITHUB_ID!, clientSecret: process.env.AUTH_GITHUB_SECRET! }),
    Credentials({
      credentials: { email: {}, password: {} },
      async authorize(credentials) {
        // find user and verify password
      },
    }),
  ],
  session: { strategy: 'database' },
  callbacks: {
    async session({ session, user }) {
      session.user.id = user.id;
      return session;
    },
  },
});

Важно: для database sessions прокидываем PrismaAdapter, для JWT — нет. Edge Runtime поддерживается автоматически при использовании App Router.

Конфигурация провайдеров

Провайдеры настраиваются в массиве providers. Для OAuth необходимо указать clientId и clientSecret из консоли разработчика. Credentials провайдер требует собственную логику проверки, но Auth.js берет на себя управление сессией и защиту от CSRF.

Защита маршрутов middleware

// middleware.ts
import { auth } from '@/auth';
export default auth((req) => {
  if (!req.auth) {
    const loginUrl = new URL('/login', req.url);
    loginUrl.searchParams.set('callbackUrl', req.url);
    return Response.redirect(loginUrl);
  }
});
export const config = { matcher: ['/dashboard/:path*', '/settings/:path*'] };

Middleware применяется ко всем маршрутам, указанным в matcher. Это простой способ защитить целые разделы без дублирования кода.

JWT или database sessions: что выбрать?

Выбор зависит от ваших приоритетов. Если важна скорость и простота — JWT. Если безопасность и контроль — database sessions. В 70% наших проектов используем database sessions с Prisma, так как это дает больше гибкости.

Процесс работы и сроки

Базовая интеграция (OAuth + JWT) занимает 1–2 дня. С database sessions и magic link — до 4 дней. Стоимость рассчитывается индивидуально под каждый проект.

Типичные ошибки при внедрении

Самая частая ошибка — неправильные переменные окружения. AUTH_SECRET обязателен, иначе сессии не будут шифроваться. Вторая проблема — забытый PrismaAdapter для database sessions, из-за чего сессии не сохраняются. Третья — отсутствие типизации сессии, что приводит к ошибкам TypeScript на этапе компиляции. Мы в каждом проекте проверяем эти моменты на код-ревью.

Почему стоит доверить аутентификацию профессионалам?

Мы занимаемся веб-разработкой 5+ лет и реализовали аутентификацию для 30+ Next.js проектов. Гарантируем стабильную работу и поддержку после внедрения. Свяжитесь с нами для консультации по вашему проекту — мы подберем оптимальную конфигурацию и реализуем аутентификацию за 1-4 дня. Закажите интеграцию Auth.js и получите готовое решение с документацией и поддержкой.

Дополнительные возможности

• Email provider: magic link без пароля — удобно и безопасно.
• Server Actions: проверка прав прямо на сервере.
• Кастомные страницы входа: свой дизайн под ваш бренд.

С нами вы получите не просто код, а проверенную архитектуру, которая выдержит нагрузку и легко масштабируется.

Аутентификация и авторизация: OAuth, JWT, сессии, RBAC, 2FA

На одном проекте токен JWT с ролью admin: false мог быть изменён клиентом на admin: true — сервер принимал его без верификации подписи. Это не гипотетическая атака: несколько файлов в npm-экосистеме имели уязвимость jwt библиотеки, которая игнорировала алгоритм none. Последствия — полный доступ к административным функциям для любого зарегистрированного пользователя.

JWT: что реально нужно знать

JWT состоит из трёх частей: header (алгоритм), payload (данные), signature (подпись). Подпись верифицирует, что payload не изменён. Без проверки подписи — это просто base64-encoded JSON, который любой может подделать.

Ошибки, которые видим в коде регулярно:

Хранение в localStorage. localStorage доступен любому JS на странице — XSS атака читает токен и отправляет на сервер злоумышленника. Access token в памяти (переменная модуля), refresh token в httpOnly cookie — правильная схема.

Долгоживущие access-токены. Access token на 7 дней без возможности отзыва. Утёк — 7 дней доступа. Стандарт: 15 минут для access token, 30 дней для refresh token с ротацией. При каждом использовании refresh token выдаётся новый, старый инвалидируется — если старый кто-то использует повторно, это детектируется как Token Reuse Attack, вся семья токенов отзывается.

Хранение секретных данных в payload. JWT payload не зашифрован, только подписан — его видно в base64. Пароли, платёжные данные, личная информация — не в JWT.

Алгоритм RS256 (асимметричный) предпочтительнее HS256 (симметричный) в микросервисной архитектуре: сервисы могут верифицировать токен публичным ключом, не имея доступа к секрету для его создания.

OAuth 2.0 и OpenID Connect

OAuth 2.0 — протокол делегированной авторизации, не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, который добавляет id_token с данными пользователя.

Authorization Code Flow с PKCE — единственный правильный flow для браузерных SPA и мобильных приложений. Implicit Flow устарел и небезопасен. PKCE (Proof Key for Code Exchange) защищает от перехвата authorization code.

Реализация OAuth сервера: не пишем с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Laravel Passport или Laravel Sanctum для серверных приложений. NextAuth.js для Next.js — поддерживает 50+ провайдеров из коробки.

Для B2B продуктов с корпоративными клиентами — SAML 2.0 SSO. Корпоративные IT-отделы часто требуют его вместо OAuth. @boxyhq/saml-jackson — node.js библиотека для SAML → OAuth2 адаптера.

Сессии vs токены

Сессии хранят состояние на сервере (Redis, database) — сервер может мгновенно отозвать сессию. При масштабировании на несколько инстансов нужен общий store (Redis Cluster). Cookie с session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не требуют server-side storage, масштабируются горизонтально. Но отзыв токена до истечения срока — только через blacklist (Redis), что частично убирает преимущество stateless.

Для большинства веб-приложений сессии проще и безопаснее. JWT имеет смысл для API, потребляемых из мобильного приложения, и для микросервисной архитектуры.

RBAC и политики доступа

Role-Based Access Control — у пользователя есть роли, у ролей — права. Простая реализация: user → roles → permissions. Но как только появляется ресурсная авторизация («пользователь может редактировать только свои посты»), RBAC усложняется.

Spatie Laravel Permission — стандарт для Laravel: полиморфные роли и права, кэширование, super-admin через gate. Интеграция с Eloquent: $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — политики на основе атрибутов: пользователя, ресурса, окружения. Нужен когда правила доступа сложные: «менеджер может просматривать заказы своего региона, если заказ создан более 24 часов назад». Casbin — популярная cross-language библиотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ определяется графом отношений: «пользователь X является участником команды Y, которая имеет доступ к проекту Z». OpenFGA — open source реализация от Okta.

Двухфакторная аутентификация

TOTP (Time-based One-Time Password, Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при подключении — base32-encoded secret, которого достаточно для воспроизведения кода при компрометации. Хранить secret в зашифрованном виде.

SMS-верификация — слабее TOTP из-за SIM-swapping атак и ненадёжности доставки SMS. Но пользователи активируют её охотнее. Email OTP — компромисс между безопасностью и UX.

WebAuthn (Passkeys) — биометрия или аппаратный ключ вместо пароля. Хранится private key на устройстве, публичный — на сервере. Нет пароля — нет его утечки. iOS 16+, Android 9+, все современные браузеры поддерживают. @simplewebauthn/server + @simplewebauthn/browser — хорошая библиотека для Node.js реализации.

Backup-коды при подключении 2FA: 10 одноразовых кодов для восстановления доступа если телефон потерян. Хранить хешированными (bcrypt), показывать только один раз при генерации.

Типичные уязвимости

Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 возвращает заказ без проверки, принадлежит ли он текущему пользователю. Самая распространённая уязвимость API по OWASP. Каждый запрос к ресурсу — проверка через $user->can('view', $order).

Mass Assignment: User::create($request->all()) — пользователь передаёт is_admin: true в теле запроса. Laravel решает через $fillable / $guarded, но часто забывают.

Небезопасный CORS: Access-Control-Allow-Origin: * на API с авторизацией по cookie — credentials не передаются с wildcard origin, но если кто-то сделал Allow-Credentials: true + Allow-Origin: * — это дыра.

Процесс работы

Архитектура авторизации проектируется до начала разработки, не добавляется потом. Выбор между сессиями и JWT, структура ролей и прав, flow для OAuth-провайдеров, план для 2FA. Penetration testing обязателен для продуктов с финансовыми данными или персональными данными пользователей.

Сроки

Базовая аутентификация (email/password + OAuth + JWT/сессии): 1–3 недели. RBAC с детальными политиками доступа: 2–4 недели. 2FA (TOTP + SMS): 1–2 недели. WebAuthn/Passkeys: 2–3 недели. Полная система аутентификации для SaaS с multi-tenancy: 4–8 недель.