#spring #spring-boot #jwt #jwt-auth
#весна #пружинный ботинок #jwt
Вопрос:
пожалуйста, избавьте меня от этого сомнения.
У меня есть приложение Spring Boot с Spring security, использующее JWT.
У меня всегда был один вопрос: как Spring хранит сгенерированные токены?
Посмотрев на менеджер моего tomcat, я увидел, что у этого приложения есть несколько открытых сеансов, но оно работает исключительно с JWT. В этом нет смысла, когда я запрашиваю открыть сеанс.
Итак, могу ли я предположить, что Spring создает сеансы для хранения сгенерированных токенов?
Комментарии:
1. Spring не хранит токены JWT. Что делает ваша библиотека JWT, так это проверяет, является ли входящий токен действительным и активным. Эта проверка выполняется на основе предоставленного секрета, а также на основе срока службы токена.
2. Большое спасибо за ответ. Итак, что происходит, когда Spring security получает токен, он просто вычисляет, является ли это допустимым токеном на основе даты истечения срока действия? И не могли бы вы сказать мне причину открытых сессий tomcat?
3. Обычно для аутентификации на основе токенов вы как разработчик явно указываете, что происходит при получении нового токена, в большинстве случаев токен расшифровывается и проверяются даты истечения срока действия. В Spring Security по умолчанию для политики создания сеанса установлено значение IF_REQUIRED, что означает, что вы получаете файл cookie сеанса, созданный автоматически. Поскольку вы используете JWT, вам следует установить для политики создания сеанса значение БЕЗ СОХРАНЕНИЯ СОСТОЯНИЯ, что означает, что у вас не должно быть созданного файла cookie сеанса.
Ответ №1:
вы проходите аутентификацию, а затем получаете токен от эмитента.
Когда этот токен передается серверу Spring, серверу ресурсов необходимо выполнить несколько проверок, прежде чем он позволит вам использовать api.
JWT не зашифрован, он есть encoded , что означает, что каждый может видеть и читать его содержимое. Но это также signed так, что вы не сможете вмешаться в его содержимое, не нарушив вывеску.
Итак, первое, что делает сервер, это проверяет подпись, чтобы убедиться, что с ней не было проблем. Это можно сделать несколькими способами, один из которых — взять токен и отправить его эмитенту и в основном спросить «привет, этот токен действителен?», и эмитент говорит «УРА» или «НЕЙ».
Это генерирует много дополнительного сетевого трафика, если ему необходимо отправить jwts обратно и в четвертую очередь для проверки.
Поскольку обозначение токенов выполняется с помощью асимметричного шифрования, сервер ресурсов может периодически (например, каждые 30 минут) запрашивать у эмитента открытый ключ, чтобы он мог проверять сами токены без постоянной необходимости спрашивать, действительны они или нет.
Этот ключ обычно отправляется в формате, называемом JWK (веб-ключ Json), и затем этот ключ используется для проверки целостности. Если эта проверка пройдет успешно, он может доверять содержимому jwts и начать проверять дату проверки, области видимости и любые дополнительные утверждения в нем и т.д.
И затем, если срок действия токена не истек, вы можете, например, выбрать создание объекта UserDetails из данных в jwt.
Как уже упоминалось в комментариях. Если вы используете JWTs, вам не нужен сеанс. вы должны отключить создание сеанса.
Вы можете прочитать гораздо больше о сеансах в этой статье здесь Spring Security Session
И здесь вы можете прочитать об управлении сеансами Spring Security