Почему JWT считается неуправляемым с сервера?

Question

Я прекрасно знаю, что такое JWT. Но это известный факт, что есть проблема с отзывом JWT.

Например, я прочитал здесь :

У нас было несколько случаев, когда мы хотели, чтобы пользователи HelpTap вышли из очистка куки, но мы не можем просить их делать это каждый раз. Также рассмотрим случай, когда мобильный телефон пользователя украден, и он хочет выйти из всех существующих сеансов (например, выйти из Gmail из других сеансов особенность). Ну, это невозможно в случае JWT.

Но если я могу сохранить информацию о пользователе в разделе данных jwt, то я также могу создать на сервере БД, которая будет проверять, следует ли отозвать конкретного пользователя.

Если это так, тогда я могу отправить новый JWT.

Вопрос:

Чего мне не хватает? Я уверен, что могу отозвать JWT конкретного пользователя и отправить ему новый.

Answer 1

JWS (то есть подписанный JWT ) использует криптографическую подпись для обеспечения целостности утверждений, поэтому многие разработчики приложений склонны использовать аутентификация без сохранения состояния : если подпись действительна, а токен не просрочен, токену можно доверять, независимо от состояния, хранящегося на сервере.

Это здорово имощный подход, но он имеет компромисс : он не дает вам большого контроля, когда вам нужно управлять отзывом токена.Так что это не подход «один размер подходит для всех» : он может хорошо работать в некоторых контекстах (например, распространение идентификаторов микросервисов), но может не подходить для всех приложений.

---

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

Чтобы достичь этого, вы можете назначить уникальный идентификатор каждому токену, а затем сохранить такой идентификатор на своем сервере.При проверке токена, помимо проверки подписи и даты истечения срока действия, вы также должны проверить, находится ли идентификатор токена в белом списке (или не в черном списке).

Наконец, утверждение jtiпредназначен для хранения уникального идентификатора в токене:

4.1.7.Заявка "jti" (идентификатор JWT)

Заявка jti (идентификатор JWT) предоставляет уникальный идентификатор для JWT.Значение идентификатора ДОЛЖНО быть назначено таким образом, чтобы обеспечить незначительную вероятность того, что одно и то же значение будет случайно назначено другому объекту данных;если приложение использует несколько эмитентов, коллизии ДОЛЖНЫ быть предотвращены среди значений, созданных разными эмитентами.Заявка jti может использоваться для предотвращения воспроизведения JWT.Значение jti является регистрозависимой строкой.Использование этого требования НЕОБЯЗАТЕЛЬНО.

Answer 2

Конечно, вы можете создать JWT, сохранить его (или его JTI) в базе данных и использовать базу данных для поиска токенов и отклонения отозванных токенов.

Но смысл JWT в том, что он не имеет статуса. Если вам нужно выполнить запрос к базе данных, чтобы проверить его, вы также можете отправить своему пользователю простой старый случайный идентификатор сеанса и получить данные пользователя на стороне сервера, которые на самом деле будут более безопасными, чем любой JWT. Используя поиск в базе данных, вы в значительной степени объединяете только недостатки JWT и сеанса, и ваш JWT едва ли больше, чем просто идентификатор сеанса с состоянием.