1

Тема: Поясніть мені Refresh Token Rotation

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

Теоретично цей токен може хтось вкрасти, і щоб запомігти цьому, при кожному логіні користувача, ми даємо йому один JWT - Access Token, та ще один JWT - Refresh Token.

Перший токен валідний лише протягом десяти хвилин, тобто, користувач зможе робити запити використовуючи цей токен лише впродовж 10-ти хвилин після того, як він його отримав, і якщо спробує використати його після 10-ти хвилин, то ми скажемо, що цей токен не робе, і користувач рахується не автентихвікованим.

Але! Refresh Token є валідним протягом довшого часу, і користувач може використовувати його для того, аби отримати новий Access Token.
Тобто, спочатку користувач отримує два токени Access та Refresh. Потім, протягом 10-ти хвилин він використовує Access Token для запитів до нашого API, а після 10-ти хвилин він робить запит на іншу адресу, нехай /refresh-token, і в цьому запиті відправляє нам Refresh Token - ми перевіряємо, чи цей токен валідний, і якщо так, то відправляємо користувачу новий Access Token.

Вся ця штука відбувається в фоновому режимі, тому користувач може користуватись сервісом без проблем, протягом того часу, доки Refresh Token валідний.

Цей Refresh Token може бути валідним протягом тижнів, а то й місяців, це вже як ми його налаштуємо. Але якщо цей токен вкраде поганий хлоп, чи дівка, то вони зможуть використовувати його для отримання нових Access Token'ів, і робити погані речі від імені користувача.

Refresh Token Rotation
Саме тому придумали Refresh Token Rotation. Ідея в тому, що при кожному запиті на отримання нового Access Token'у, ми так само відправляємо новий Refresh Token, далі ми повинні десь зберігати усі використані Refresh Token'и, і як тільки ми бачимо, що якийсь Refresh Token був використаний двічі - це означає, що хтось вкрав його, і тому нам треба "інвалідувати всі токени цього сімейства". Я це розумію так, що коли ми отримали перший Refresh Token, то потім, використовуючи його ми можемо отримати ще один, новий, і ось ми повинні всі ці токени "з одного сімейства" зберігати в базі даних, і як тільки один з них використовується двічі - ми заносимо їх всі в чорний список в базі даних, і тепер жоден з цих токенів не можна використати, аби отримати новий токен.

Але я не розумію, навіщо нам зберігати всі токени, і потім заносити їх в чорний список, якщо ми можемо лише зберігати останній виданий токен в білому списку?

Наприклад: користувач логіниться, і отримує Access та Refresh токени. При цьому виданий Refresh Token зберігається в базі даних, і він є асоційований з цим конкретним користувачем. Тепер, якщо погані люди вкрадуть цей Refresh Token у користувача, та спробують використати його, аби отримати нові Refresh та Access токени, старий токен, який ми зберігали в базі даних перезапишеться новим токеном, тому як тільки користувач спробує зробити те саме, ми помітимо, що Refresh Token відправлений користувачем не є в нашому білому списку, тому що він був перезаписаний новим токеном, котрий отримали погані люди, і в цей момент ми просто видалимо токен з білого списку, і ніхто тепер не зможе отримати нові Refresh та Access токени. Але якщо користувач залогіниться знову, то він отримає знову пару нових токенів, і зможе їх використовувати.

2

Re: Поясніть мені Refresh Token Rotation

По-перше ідея була, що токени видає один сервіс, а використовуєш ти їх на іншому.
По-друге, ти можеш залогінитись з різних аплікацій на сервісі авторизації і кожна з цих аплікацій одержить свій рефреш токен.

3

Re: Поясніть мені Refresh Token Rotation

Vo_Vik написав:

По-перше ідея була, що токени видає один сервіс, а використовуєш ти їх на іншому.
По-друге, ти можеш залогінитись з різних аплікацій на сервісі авторизації і кожна з цих аплікацій одержить свій рефреш токен.

тобто моя ідея з білим список не робе?
а якщо нам треба, аби лише один користувач міг залогінитись в певний акаунт, і шоб два одночасно не було?

4 Востаннє редагувалося Vo_Vik (25.09.2021 16:17:56)

Re: Поясніть мені Refresh Token Rotation

Ви говорите про систему, яка і видає токени і їх використовує. Таке використання не є таким для чого придумали jwt, так що для вашої системи можете робити ту імплементацію, яка вам більше підходить

5

Re: Поясніть мені Refresh Token Rotation

Vo_Vik написав:

Ви говорите про систему, яка і видає токени і їх використовує. Таке використання не є таким для чого придумали jwt, так що для вашої системи можете робити ту імплементацію яка вам більше підходить

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