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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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