Архітектура автентифікації в Next.js

Коротка відповідь

Використовуйте підтримувану auth-інтеграцію, перевіряйте сесію на сервері й дозволяйте кожне приватне читання та зміну біля даних. Proxy чи layout допомагають навігації, не замінюють перевірку. Дійсна сесія підтверджує користувача, не доступ до всіх tenant і admin-операцій.

Практичні кроки реалізації

1. Централізуйте перевірену сесію

Один серверний reader кращий за окремий parsing cookies у pages, actions і handlers. Протокол і криптографію передайте інтеграції. Визначте expiry, logout і revocation. Email, role чи ID браузера й неперевірений token не є доказами.

2. Перевірте scope до проєкції

Report lookup поєднує ID з дозволеним owner чи tenant. Role-винятки явні, не загальне isLoggedIn. Повертайте лише потрібні поля. Сервер може витекти через HTML, props, errors і metadata; місце виклику бази — лише частина захисту.

3. Захистіть усі мутації

Прихована кнопка не блокує прямий Server Action чи API. Перевіряйте сесію й дозвіл у виклику, валідуйте вхід і використовуйте origin/CSRF-захист інтеграції. Return URL обмежте origin. Після logout чи role-зміни перевірте кеш і відкритий UI.

Приклад реалізації

Функція припускає перевірену серверну сесію й scoped-read report. Вона не перевіряє token і не приймає довільну client-identity. Для multi-tenant додайте membership і tenant-фільтр. Політика належить дозволеній операції для всіх точок входу.

type VerifiedUser = { id: string; role: "member" | "admin" };
type Report = { id: string; ownerId: string };

export function canReadReport(
  user: VerifiedUser | null, report: Report,
): boolean {
  if (!user) return false;
  return user.role === "admin" || report.ownerId === user.id;
}

Репозиторій використовує NextAuth, GitHub sign-in і дозволений login у callback; стратегія сесії JWT. Це факти обмеженого admin-портфоліо, не enterprise-role система й не доказ live-OAuth тесту під час редакційного огляду.

Компроміси та альтернативи

Identity provider підтримує протокол, але дозволи лишаються продукту. Database-сесії спрощують revocation; stateless потребують політики свіжості ролей. JWT не усуває стан, cookies — ризики. Тут місце перевірок; формат сесії — інше рішення.

Поширені помилки

Головні помилки: лише layout, client-role, ID-read без scope і приватний результат у public-cache. Повні записи не передаються як props. Errors і logs також потребують проєкції: записи й tokens не показують відвідувачу.

Перевірка перед випуском

• ☐ Приватні точки входу перевіряють сесію.
• ☐ Дозволи обмежують читання запису й tenant.
• ☐ Мутації повторно перевіряють вхід і дозвіл.
• ☐ Client output не має секретів.
• ☐ Logout, expiry і role-зміни визначено.

Поширені запитання

Чи достатньо proxy?

Ні. Proxy допомагає маршруту, а остаточна перевірка належить операції. Не всі виклики проходять один UI.

Чи можливий спільний layout?

Так, але public має безпечний кеш, private — авторизацію. Не робіть усі публічні маршрути випадково залежними від сесії.

Наступний крок

Перелічіть pages, handlers і actions з приватними даними. Зведіть до шару сесії й дозволів та перевірте expiry, заборони й role-зміни. Redirect додавайте після правильного доступу.

Первинні джерела

• Next.js: архітектура автентифікації
• Next.js: безпека даних

Пов’язані матеріали та приклади

• React, Next.js і TypeScript
• Зручна для підтримки структура проєкту Next.js App Router
• Серверні та клієнтські компоненти React: порівняння
• Завантаження даних у Next.js App Router
• Публічний каталог проєктів