Подтвердить что ты не робот

JWT обновляет токен потока

Я создаю мобильное приложение и использую JWT для аутентификации.

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

  • Как выглядит токен обновления? Это случайная строка? Эта строка зашифрована? Это еще один JWT?
  • Ток обновления будет храниться в базе данных в пользовательской модели для доступа, правильно? Кажется, он должен быть зашифрован в этом случае
  • Я отправил бы токен обновления после входа пользователя в систему, а затем попросит клиент получить доступ к отдельному маршруту для получения токена доступа?
4b9b3361

ОТВЕТЫ

Ответ 1

Предполагая, что это о OAuth 2.0, поскольку речь идет о JWT и обновлении токенов...:

  • как токен доступа, в принципе токен обновления может быть любым, включая все параметры, которые вы описываете; JWT может использоваться, когда сервер авторизации хочет быть без гражданства или хочет применить какую-то семантику "доказательства владения" для клиента, представляющего его; обратите внимание, что токен обновления отличается от токена доступа тем, что он не отображается на сервере ресурсов, а только на сервере авторизации, который его выдал, в первую очередь, поэтому автономная оптимизация проверки для JWT-атак-токенов не удерживать для токенов обновления

  • который зависит от безопасности/доступа к базе данных; если к базе данных могут обращаться другие стороны/серверы/приложения/пользователи, то да (но ваш пробег может отличаться в зависимости от того, где и как вы храните ключ шифрования...)

  • Сервер авторизации может одновременно выпускать токены доступа и обновлять токены в зависимости от гранта, который используется клиентом для их получения; спецификация содержит детали и опции для каждого стандартизованного гранта.

Ответ 2

На основе этой реализации с Node.js из JWT с токеном обновления:

1) В этом случае они используют UID, а не JWT. Когда они обновляют токен, они отправляют токен обновления и пользователю. Если вы реализуете его как JWT, вам не нужно отправлять пользователя, потому что это будет внутри JWT.

2) Они реализуют это в отдельном документе (таблица). Это имеет смысл для меня, потому что пользователь может войти в различные клиентские приложения и может иметь маркер обновления для приложения. Если пользователь потеряет устройство с одним установленным приложением, токен обновления этого устройства может быть признан недействительным, не затрагивая другие подключенные устройства.

3) В этой реализации это ответ на метод входа с токеном доступа и токеном обновления. Это кажется мне правильным.

Ответ 3

Ниже приведены инструкции по отзыву вашего токена доступа JWT:

1) Когда вы входите в систему, отправьте 2 токена (токен доступа, токен обновления) в ответ клиенту.
2) У маркера доступа будет меньше время истечения, а у обновления будет долгое время истечения.
3) Клиент (Front end) будет хранить токен обновления в своем локальном хранилище и токен доступа в куки.
4) Клиент будет использовать токен доступа для вызова API. Но когда он истекает, выберите токен обновления из локального хранилища и вызовите сервер аутентификации api, чтобы получить новый токен.
5) На вашем сервере аутентификации будет открыт API, который примет токен обновления, проверит его действительность и вернет новый токен доступа.
6) Когда срок действия маркера обновления истечет, пользователь выйдет из системы.

Пожалуйста, дайте мне знать, если вам нужна дополнительная информация, я также могу поделиться кодом (Java + Spring boot).

По вашим вопросам:
Очередь 1: Это еще один JWT с меньшим количеством претензий с длительным сроком действия.

Que 2: это не будет в базе данных. Бэкенд не будет хранить нигде. Они просто дешифруют токен с помощью закрытого/открытого ключа и проверяют его также по истечении срока его действия.

Que3: Да, правильно