Next. js Стратегии аутентификации

Question

Я пытался реализовать надежный поток аутентификации для проекта Next. js, но сейчас я полностью потерян. Я уже видел примеры репозитория Next. js. Но у меня много вопросов для полного решения.

У меня есть express. js API и отдельный интерфейс Next. js. Все данные и аутентификация обрабатываются API. Frontend просто отображает страницы с помощью SSR. Если бы я просто создал монолитный проект, в котором рендеринг страниц и всех данных обрабатывался бы одним сервером (с пользовательской опцией сервера для Next. js Я имею в виду), я бы просто использовал express -session и csurf. , Это был бы традиционный способ управления сеансами и создания защиты от CSRF.

Express. js API не требуется. Это всего лишь пример. Это может быть Django API или. Net Core API. Главное, это отдельный сервер и отдельный проект.

Как я могу иметь простую, но надежную структуру? Я изучил некоторые из моих любимых веб-сайтов (netlify, zeit.co, heroku, spectrum.chat et c). Некоторые из них используют localalstorage для хранения доступа и обновления токенов sh (уязвимость XSS). Некоторые из них используют куки, и они даже не HTTPOnly (XSS и CSRF уязвимы). И примеры, такие как spectrum.chat, используют способ, который я упомянул выше (cook ie -сессия + предотвращение csrf).

Я знаю, что вокруг токенов JWT есть гигантский обман. Но я нахожу их слишком сложными. Большинство уроков просто пропускают все истечение срока действия, обновление токенов, отзыв токенов, черные списки, белые списки и т. Д. c.

И многие из сеансов готовят ie примеров для Next. js почти никогда не упоминают CSRF , Честно говоря, аутентификация всегда большая проблема для меня. Однажды я прочитал, что HTTPOnly файлы cookie должны использоваться, на следующий день я вижу гигантский популярный сайт, который даже не использует их. Или они говорят «никогда не храните свои токены в localStorage», и бум какой-то гигантский проект просто использует этот метод.

Может кто-нибудь показать мне какое-то направление для этой ситуации?

Answer 1

Мне тоже пришлось подумать об этом для моего текущего проекта. Я использую те же технологии: API ExpressJS и интерфейс * Next JS на стороне сервера.

Я решил использовать паспорт. js в ExpressJS API. TheNetNinja на YouTube имеет действительно хороший плейлист с 21 эпизодом. Он показывает вам, как реализовать Google OAuth 2.0 в вашем API, но этот лог c переносится на любую другую стратегию (JWT, электронная почта + пароль, аутентификация Facebook и т. Д. c.).

В передней части В конце концов, я бы буквально перенаправил пользователя на URL в Express API. Этот URL-адрес будет показывать пользователю экран Google OAuth, пользователь нажимает «Разрешить», API делает еще кое-что, готовит ie для указанного пользователя c, а затем перенаправляет обратно на URL-адрес во внешнем интерфейсе. , Теперь пользователь прошел проверку подлинности.

О файлах cookie HTTPOnly: я решил отключить эту функцию, потому что я сохранял в файле Cook ie информацию, которая мне была нужна во внешнем интерфейсе. Если у вас включена эта функция, то интерфейс (javascript) не имеет доступа к этим куки, потому что они HTTPOnly.

Вот ссылка на плейлист, о котором я говорил: https://www.youtube.com/watch?v=sakQbeRjgwg&list=PL4cUxeGkcC9jdm7QX143aMLAqyM-jTZ2x

Надеюсь, я дал вам направление, которое вы можете выбрать.

РЕДАКТИРОВАТЬ: Я не ответил на ваш вопрос о CSURF, но это потому, что я не знаком с ним.

Answer 2

Я наконец-то нашел решение!

Теперь я использую пакет csrf npm, а не csurf. csurf просто превращает csrf в express промежуточное ПО.

Итак, я создаю csrfSecret в getInitialProps _app. Он создает секрет, устанавливает его как httpOnly cook ie. Позже он создает csrfToken и возвращает его с pageProps. Таким образом, я могу получить к нему доступ через окно. NEXT_DATA .props.csrfToken. Если пользователь обновляет страницу, csrfSecret остается прежним, но csrfToken обновляется.

Когда я делаю запрос к прокси-маршруту "/ api / graphql API, он сначала получает токен csrf из x-xsrf-token заголовок и проверяет его с помощью значения csrfSecret cook ie. После этого он извлекает значение authToken cook ie и передает его фактическому API-интерфейсу GraphQL.

API полностью основан на токене. токен доступа с неограниченным сроком действия. (Кстати, это не обязательно должен быть JWT. Можно использовать любой криптографически стойкий случайный токен. Это означает, что эталонный / непрозрачный токен.)

Проверка CSRF не нужна для фактический API, потому что он не использует куки для аутентификации. Он только проверяет заголовок авторизации. И authToken, и csrfSecret - это куки httpOnly. И я даже никогда не сохраняю их в памяти на стороне клиента.

Я так думаю настолько безопасен, насколько я мог. Теперь я доволен этим решением.