Поток токенов обновления JWT


129

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

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

  1. Как выглядит токен обновления? Это случайная строка? Эта строка зашифрована? Это еще один JWT?
  2. Токен обновления будет храниться в базе данных модели пользователя для доступа, верно? Похоже, в этом случае он должен быть зашифрован
  3. Могу ли я отправить токен обновления обратно после входа пользователя, а затем предоставить клиенту доступ к отдельному маршруту для получения токена доступа?

3
Обратите внимание: если вы используете токены обновления, вы должны предоставить пользователям возможность аннулировать их в пользовательском интерфейсе. Также рекомендуется автоматически аннулировать их, если они не используются, например, в течение месяца.
Вилмантас Баранаускас

1
@jtmarmon: как вы храните токен обновления на стороне клиента? Я имею в виду устройство Android с безопасностью?
j10

Ответы:


39

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

  1. как и токен доступа, в принципе токен обновления может быть любым, включая все описанные вами параметры; JWT может использоваться, когда сервер авторизации хочет быть без состояния или хочет навязать своего рода семантику «доказательства владения» клиенту, представляющему его; обратите внимание, что токен обновления отличается от токена доступа тем, что он не предоставляется серверу ресурсов, а только серверу авторизации, который его выпустил в первую очередь, поэтому автономная оптимизация проверки для JWT-as-access-tokens действительно не удерживать токены обновления

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

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


31
2. Вы должны сохранить хэш токена обновления в своей базе данных, а затем сравнить хэш токена обновления пользователя с вашим сохраненным хешем. Здесь следует правило «не хранить пароли в виде обычного текста в базе данных». Считайте токен случайным паролем, который вы создали для пользователя.
Rohmer

2
Кроме того, если вы хотите обеспечить большую безопасность, также выполните ротацию токенов обновления. Важность этого уже упоминается в ITEF RFC 6749 . При правильной реализации это также может помочь в выявлении сценария кражи токена, т. Е. Токен обновления был украден злоумышленником. Если вы ищете лучшее объяснение,
перейдите

85

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

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

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

По вашим вопросам:

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

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

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


28
Я думаю, что JWT следует хранить, localStorageа refreshTokenфайл - в httpOnly. Его refreshToeknможно использовать для получения нового JWT, поэтому с ним нужно обращаться с особой осторожностью.
Tnc Андрей

2
Спасибо, что вы имеете в виду под хранением в httpOnly? Почему бы не хранить и то, и другое в localStorage?
Джей

8
Мне не хватает преимуществ использования токена обновления, разве не продлить срок действия токена доступа?
user2010955

3
@Jay Согласно Microsoft Developer Network, HttpOnly - это дополнительный флаг, включенный в заголовок HTTP-ответа Set-Cookie. Использование флага HttpOnly при создании файла cookie помогает снизить риск доступа сценария на стороне клиента к защищенному cookie (если браузер поддерживает его).
shadow0359

23
№2 очень неточен. Токен обновления ДОЛЖЕН храниться на стороне сервера. Вы не должны использовать "автономное" свойство JWT для токена обновления. Это не оставляет вам возможности отозвать токены обновления, кроме изменения вашего закрытого ключа.
Джай Шарма

26

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

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

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

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


Говоря «1) В этом случае они используют uid ...», вы имели в виду UUID?
ozanmuyes 08

Как насчет этой более простой реализации - проблема JWT - отправить старый JWT, когда вы хотите обновить - (вы можете проверить iatс помощью окна) - переиздайте новый, основанный на предыдущем
adonese

@adonese, отправив только то, что JWTвы хотите иметь refresh_tokenвнутри? Если это так, OAuth RFC 6749 явно говорит не отправлять refresh_tokenна сервер ресурсов (иJWT отправляется на серверы ресурсов): tools.ietf.org/html/rfc6749#section-1.5
Коста
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.