Где хранить веб-токены JSON (JWT)?

Я занимаюсь проектированием и разработкой веб-приложений более 7 лет.

За эти годы я увидел множество механизмов аутентификации, некоторые из них являются RESTful, а другие нет. Службы RESTful в основном использовали JSON Web Token (JWT) в качестве токена аутентификации.

Всякий раз, когда я внедрял аутентификацию на основе JWT, я задавал себе этот вопрос: «Где мы храним JWT?»

Изменить: Эта статья посвящена только реализации в браузере.

Давайте ответим на большой вопрос.

У нас есть три варианта хранения данных на стороне клиента, и каждый из них имеет свои преимущества и недостатки. Возможны следующие варианты:

1. Cookie-файлы
2. localStorage
3. Сессионное хранилище

Cookie

Если вы установите JWT для cookie, браузер автоматически отправит токен вместе с URL-адресом для запроса того же сайта. Но уязвим для CSRF.

Мы можем защитить сайт от CSRF, установив файл cookie с SameSite=strict

Edit 1: В общем люди могут подумать, ̶ XSS может быть побежден, если положить HTTPOnly FLAG, ̶ но это можно атаковать с помощью XST ̶»подмножеством» ̶ ̶ (Любопытное) ̶ из XSS .̶

Редактировать 2: мы можем легко вывести из строя XSS, установив флаг httpOnly.

Плюсы:

1. Браузер автоматически отправит токен на сервер.
2. Один и тот же токен доступен на нескольких вкладках вашего экземпляра приложения.

Против:

1. Уязвим к XSS.
2. Вам необходимо прикрепить токен в заголовке, если вы используете протокол типа OAuth 2.0.

localStorage

LocalStorage не отправляет данные автоматически вместе с URL-адресом. Поэтому вам необходимо реализовать систему для токена аутентификации для каждого URL-адреса. Но самое приятное то, что этот метод не уязвим для CSRF.

Плюсы

1. Не уязвим для CSRF.
2. Один и тот же токен доступен на нескольких вкладках вашего экземпляра приложения.

Con

1. Уязвим к XSS.
2. Вам необходимо реализовать механизм для отправленного токена.

Хранилище сеанса

Хранилище сеансов почти такое же, как локальное хранилище, за исключением того, что токен будет доступен только на одной вкладке, после закрытия вкладки сеанс будет уничтожен. Так что это бесполезно для такой функции, как запомнить меня. Но это можно использовать в функции множественного входа, например, вкладка A находится в другом логине, а вкладка B - в другом.

Плюсы:

1. Не уязвим для CSRF.
2. Легко реализовать несколько входов в один браузер.

Против:

1. Уязвим к XSS.
2. Как только вкладка закрывается, данные сеанса уничтожаются.

Вы могли заметить, что все 3 метода имеют один и тот же символ - Уязвим к XSS. Да, все эти методы уязвимы для XSS. Пожалуйста, заботьтесь о XSS и всегда следуйте лучшим практикам для защиты от XSS.

Заключение

И localStorage, и SessionStorage по умолчанию не защищены XSS.

Однако Cookie предоставляет набор параметров безопасности, таких как SameSite, HttpOnly и т. Д. Так что лучше использовать Cookie.

«Храните JWT в файлах cookie с флажком безопасности».

Примечание:

Если вы используете Express, эти пакеты могут помочь повысить безопасность вашего приложения.

Также ознакомьтесь с моими недавними статьями

1. Глубокое погружение в тряску деревьев (Как уменьшить размер пакета)
2. 5 шаблонов бесконечного цикла useEffect

Я обнаружил, что эти статьи полезны для меня, может быть, они могут быть полезны для вас.

Больше контента на plainenglish.io