JWT оновить потік токенів

Я будую мобільний додаток і використовую JWT для аутентифікації.

Здається, найкращий спосіб зробити це - з’єднати маркер доступу JWT з маркером оновлення, щоб я міг закінчувати термін доступу так часто, як мені хочеться.

1. Як виглядає маркер оновлення? Це випадковий рядок? Це рядок зашифровано? Це інший JWT?
2. Маркер оновлення зберігатиметься в базі даних на користувацькій моделі для доступу, правда? Здається, в цьому випадку його слід зашифрувати
3. Чи надсилаю я маркер оновлення після входу користувача, а потім клієнт має доступ до окремого маршруту, щоб отримати маркер доступу?

Якщо припустити, що мова йде про OAuth 2.0, оскільки мова йде про JWT та оновлення жетонів ...:

1. подібно до маркера доступу, в принципі маркер оновлення може бути будь-яким, включаючи всі описані вами варіанти; JWT може бути використаний, коли сервер авторизації хоче бути без громадянства або хоче застосувати якусь семантику "підтвердження володіння" для клієнта, який його представляє; зауважте, що маркер оновлення відрізняється від маркера доступу тим, що він подається не на сервер ресурсів, а лише на сервер авторизації, який видав його в першу чергу, тому автономна оптимізація перевірки JWTs-as-access-tokens робить не тримати для оновлення маркерів

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

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

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

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

Будь ласка, повідомте мені, якщо вам потрібні додаткові деталі, я можу поділитися кодом (Java + Spring boot).

Для ваших питань:

Q1: Це ще один JWT з меншою кількістю претензій, поданих із тривалим терміном дії.

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

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

На основі цієї реалізації з Node.js JWT з маркером оновлення :

1) У цьому випадку вони використовують uid і це не JWT. Коли вони оновлюють маркер, вони надсилають маркер оновлення та користувача. Якщо ви реалізуєте його як JWT, вам не потрібно надсилати користувача, оскільки він би знаходився всередині JWT.

2) Вони реалізують це в окремому документі (таблиці). Для мене це має сенс, оскільки користувач може входити в різні клієнтські програми, і це може мати ознаку оновлення в додатку. Якщо користувач втратить пристрій із встановленим одним додатком, маркер оновлення цього пристрою може бути недійсним, не впливаючи на інші пристрої, які ввійшли в систему.

3) У цій реалізації він реагує на метод входу з обома, маркер доступу та маркер оновлення. Мені це здається правильним.