Вопрос или проблема
Когда я ищу или изучаю, я всегда слышу об этом:
- О токене: хранится на клиенте, сервер без состояния, серверу не нужно хранить данные пользователя.
- И сессии: хранится на сервере, сервер с состоянием, …
Тем не менее, когда я использую токен
- Для выхода, я всегда храню данные (черный список/белый список/…) на сервере (сервер/redis/база данных)
- Для пользователей с большим объемом данных, например: вложенные разрешения (я всегда должен проверять это в промежуточном ПО), я храню это на сервере (redis). Потому что HTTP ограничивает передачу данных.
В это время сервер не является без состояния.
Таким образом, я думаю, что токен (JWT) – это своего рода сессия. Это правильно?
Я также интересуюсь токеном. Вы когда-нибудь использовали только токен без хранения данных на сервере?
Так что я не вижу много преимуществ от JWT.
Ответ или решение
JWT (JSON Web Token) действительно может вызывать путаницу в контексте сессий и авторизации, поскольку он обладает как свойствами, общими с сеансами (session), так и особенностями, которые отличаются от привычного подхода к работе с сессиями на сервере.
Сравнение JWT и сессий
-
Состояние сервера:
- Сессии: Традиционные сессии требуют от сервера хранения состояния пользователя, так как данные сессии (например, информация об аутентификации и авторизации) хранятся на сервере. Сессии являются «состоянием на сервере», что делает сервер «состоянием» (stateful).
- JWT: JSON Web Token – это токен, который обычно хранится на стороне клиента и содержит закодированную информацию о пользователе и его правах. При этом сервер не хранит информацию о пользователе между запросами, что делает его «бессостоянием» (stateless).
-
Использование на сервере:
- Вы правильно отметили, что в случаях, когда необходимо хранить информацию о пользователе, такие как «черные» или «белые» списки, сервер фактически становится «состоянием». Это может произойти, если используется сторонняя система, например, Redis или база данных, для хранения данных, связанных с токенами.
- Если у вас есть сложная структура с большими данными, например, вложенные разрешения, то действительно может потребоваться серверная проверка, которая заставит сервер хранить часть данных о состоянии, что снижает преимущества использования JWT как полностью бессостояного подхода.
Преимущества и недостатки JWT
-
Преимущества JWT:
- Легкость: JWT легко отправлять через URL или в заголовках HTTP, что облегчает аутентификацию в RESTful API.
- Безопасность: JWT можно подписывать и шифровать, что позволяет удостоверять идентичность и защищать данные.
- Это позволяет распределенным системам (например, микросервисам) проверять подлинность без необходимости обращаться к общему хранилищу состояния.
-
Недостатки JWT:
- Поддержка текущего состояния (например, истечение срока действия токена) и отзыва токенов требует дополнительных мер (например, черные списки), что может свести на нет его преимущества.
- Увеличение размера токена, так как он содержит все необходимые данные (в отличие от идентификатора сессии, который указывает на серверное хранилище).
Выводы
Таким образом, хотя JWT действительно может выполнять функции, схожие с сессиями, он, по своей сути, не является классической сессией. JWT предоставляет возможность реализации статeless-аутентификации, но его преимущества могут уменьшаться, если серверу необходимо хранить состояние для управления токенами или сложными правами доступа.
Если ваш проект требует значительного состояния, возможно, стоит рассмотреть комбинированный подход, где используется как JWT для аутентификации, так и серверные хранилища для управления более сложными аспектами прав доступа.
Заключение
В конечном итоге, выбор между использованием JWT или традиционных сессий зависит от конкретных требований вашего приложения. Так что ответ на ваш вопрос: JWT можно рассматривать как «состояние без состояния», но не как традиционная сессия в том смысле, в котором её обычно понимают в контексте серверного хранения.