Аутентификация в Next.js: быстрый старт

Authentication появился недавно: @didit-protocol/auth-nextjs и серверный верификатор ядра зависят от релиза. До выпуска пакета не предусмотрены ни путь импорта middleware, ни имя cookie, ни форма возвращаемого значения auth(). Токены доступа представляют собой JWT с алгоритмом ES256: проверяйте их по JWKS вашего приложения, а когда нужно узнать, что сессия всё ещё активна, вызывайте GET session/.

Храните сессию на своём сервере

Используйте размещённый сценарий, описанный в кратком руководстве по JavaScript, с такими изменениями для приложения с серверным рендерингом. Ваши маршруты являются маршрутами приложения, которые вы реализуете сами, а не эндпоинтами API Didit.

Маршрут приложения	Зона ответственности
Начало входа	Сгенерируйте state и S256 PKCE; сохраните транзакцию в короткоживущей серверной сессии; перенаправьте на `{origin}/sign-in`.
Зарегистрированный обработчик обратного вызова	Проверьте state и срок действия, однократно используйте транзакцию, обменяйте код через `token/` и сохраните токены на сервере.
Защищённая страница или маршрут API	Прочитайте cookie сессии и проверьте access-токен конечного пользователя по вашему JWKS или через `session/`, если отзыв должен вступать в силу мгновенно; авторизуйте запрошенное действие для этого человека.
Обновление	Выполняйте обновление последовательно для каждой сессии, вызовите `token/` и атомарно замените пару токенов.
Выход	Мутация с защитой от CSRF, которая отзывает `session/` и очищает сессию приложения.

Отправляйте только случайный идентификатор сессии приложения в cookie с атрибутами Secure, HttpOnly, SameSite=Lax и путём, ограниченным нужной областью действия. Задайте подходящий срок жизни и ротируйте идентификатор после входа. Не передавайте refresh-токен Didit в отрисованные props, клиентские компоненты или браузерное хранилище. Используйте Cache-Control: no-store для ответов с токенами и ответов callback. Не полагайтесь только на проверку в layout или middleware: авторизуйте каждый доступ к данным и каждую мутацию. Защищайте от CSRF мутации, аутентифицируемые с помощью cookie. Разрешайте только настроенные адреса перенаправления после входа и никогда не принимайте произвольный returnTo из строки запроса.

Предварительный просмотр релиза пакета

Запланированный пакет добавит middleware, серверный auth(), маршрут callback и поддержку HttpOnly cookie для серверной отрисовки. Предполагается, что серверная точка входа core /server будет предоставлять verifyToken() с кешированным JWKS. Дождитесь экспортов из проверенного релиза, прежде чем использовать эти символы. До тех пор проверяйте токены самостоятельно с помощью любой JOSE-библиотеки, как описано в токенах и JWKS.

Подключение других продуктов

Создавайте сессии верификации и выпускайте токены мониторинга с заданными областями действия на сервере. Формируйте vendor_data из проверенного сопоставления с человеком. В браузер возвращайте только URL сессии верификации или короткоживущий токен SDK. Не допускайте попадания DIDIT_API_KEY в публичные переменные окружения. Для верификации используйте существующий веб-SDK верификации, а для мониторинга руководство по отправке транзакций. Ни один из них не является менеджером сессий аутентификации. Протестируйте до релиза повторное воспроизведение callback, неверный state, истекший state, гонки при обновлении, отозванные сессии, отклонение CSRF-запросов и выход. См. токены и JWKS для контракта проверки.

Руководства