Нехай у нас є 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 токени. Але якщо користувач залогіниться знову, то він отримає знову пару нових токенів, і зможе їх використовувати.