Как использовать jwt в auth?

Недавно я решил просмотреть потоки аутентификации и доступные решения на сегодняшний день. Проще говоря, меня интересуют 2 варианта: Сессии / файлы cookie и JWT.

Проверим 1-й. Сеансы - это «старая, но золотая» технология, которая до сих пор широко используется в большинстве серверных приложений.

Преимущества сессий / файлов cookie

  • Легко использовать
  • Зашифрованный
  • Защищен от XSS-атак (с флагом httpOnly)
  • Защищен от CSRF-атак (с флагом sameSite)
  • Легко установить срок действия
  • Легко управлять со стороны сервера, установив соответствующие заголовки
  • Возможно масштабирование с использованием хранилища сеансов (например, Redis)

Недостатки

  • Маленький размер (4кб)
  • Используется в серверных приложениях и не подходит для SPA (одностраничных приложений)
  • Проблема с междоменными запросами
  • Поскольку многие приложения могут использовать один API, управлять аутентификацией с помощью сеансов сложно.
  • SSO (Single Sign On) - как реализовать?
  • Нужен дополнительный сервер для хранения данных сеанса
  • Необходимо запрашивать базу данных для каждого запроса (чтобы проверить идентификатор пользователя)

Итак, в современном мире JWT пришел для решения проблем.

Преимущества JWT

  • Безопасность по своей природе
  • Без сохранения состояния, подходит для любой платформы (веб, мобильная)
  • Лучше всего подходит для Restful API
  • Широко используется в SSO (единый вход)
  • Нет необходимости запрашивать базу данных на стороне сервера (для проверки идентификатора пользователя), поскольку токен может содержать неизменяемые данные
  • Хорошо подходит для безопасной передачи данных между сторонами, так как подделать данные невозможно.

Недостатки

  • Больше по размеру
  • Непросто управлять со стороны сервера
  • Нужно вручную отправить его с заголовками со стороны клиента

После долгого чтения по этой теме я все еще не могу понять, как правильно работать с JWT. Поговорим о стороне клиента и о том, как хранить JWT.

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

С другой стороны, допустим, у нас есть СПА, сейчас это популярно. От Документация Auth0

Single page applications

If you have a single page application (SPA) with no corresponding backend server, your SPA should request new tokens on page load and store them in memory without any persistence. To make API calls, your SPA would then use the in-memory copy of the token.

Означает ли это, что мне нужно входить в систему и получать токен при каждом обновлении страницы? - Да ладно, это не выход. Я хочу, чтобы пользователь оставался в системе.

Итак, вернемся к обычным серверным веб-приложениям с сеансами / файлами cookie? Я лично предпочитаю JWT, так как лучше всего использовать JWT? Буду признателен за любое ясное объяснение. Спасибо!

2
0
268
1

Ответы 1

JWT по своей природе небезопасен. Это плохой или безопасный стандарт. http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Что касается того, как сохранить пользователей в системе SPA, вы можете использовать сеанс. Сохраните ключ сеанса в файле cookie, а затем отправьте вызов REST API на бэкэнд для загрузки данных пользователя / сеанса при загрузке страницы.

В качестве альтернативы используйте поток аутентификации, в котором вы перенаправляете пользователя на сервер ID, когда они загружают приложение. После этого сервер идентификации может иметь набор cookie и управлять аутентификацией без необходимости повторного входа пользователя в систему. Это похоже на решение SPA, о котором вы спрашивали, но пользователь этого не заметит.

Другие вопросы по теме