В процессе аутентификации OAuth2 токены обновления следует использовать только один раз. Когда refresh_token используется, он вернет новый access_token и новый refresh_token.
Это тоже в RFC6819 спецификации:
5.2.2.3. Обновить ротацию токенов
Ротация токена обновления предназначена для автоматического обнаружения и предотвращения попыток параллельного использования одного и того же токена обновления из разных приложений / устройств. Это происходит, если токен украден у клиента и впоследствии используется как злоумышленником, так и легитимным клиентом. Основная идея состоит в том, чтобы изменять значение токена обновления при каждом запросе обновления, чтобы обнаруживать попытки получить токены доступа с использованием старых токенов обновления. Поскольку сервер авторизации не может определить, пытается ли злоумышленник или легитимный клиент получить доступ, в случае такой попытки доступа действительный токен обновления и связанная с ним авторизация доступа аннулируются.
Спецификация OAuth поддерживает эту меру в том смысле, что ответ токена позволяет серверу авторизации возвращать новый токен обновления даже для запросов с типом предоставления «refresh_token».
Примечание: Эта мера может вызвать проблемы в кластерных средах, поскольку необходимо гарантировать использование действующего в настоящий момент токена обновления. В такой среде могут быть более подходящими другие меры.
Это также позволяет серверу аутентификации распознать, что refresh_token был скомпрометирован, так как его следует использовать только один раз. Если новый запрос на продление с тем же refresh_token приходит на сервер аутентификации, знает, что происходит что-то подозрительное.
Интересно, как сервер должен справиться с таким сценарием? Я предполагаю, что по крайней мере все access_tokens для этого конкретного клиента должно быть признано недействительным напрямую.
Как серверы OAuth2 обычно обрабатывают несколько запросов, используя один и тот же refresh_token?
Аннулирование токенов доступа
Вы не можете аннулировать все токены доступа для определенного client_id. Client_id обычно привязан к одному приложению, но это приложение используется большим количеством пользователей. И даже один пользователь может использовать одно и то же приложение с разных устройств. Маркер обновления создает своего рода сеанс - он должен быть уникальным для конкретного приложения, пользователя и устройства. Кроме того, клиент может вызвать токен обновления с более узкой областью действия, и в этом случае вы не хотите аннулировать старый токен доступа с более широкой областью действия - клиент все еще может его использовать.
С моим ограниченным опытом серверы OAuth не аннулируют токены доступа при вызове токена обновления. Токены доступа недолговечны, они просто истекают вовремя.
Обновить токен несколько запросов
Видеть RFC6819 раздел 6: Сервер авторизации МОЖЕТ выдать новый токен обновления ... Сервер авторизации МОЖЕТ отозвать старый токен обновления после выдачи клиенту нового токена обновления. Спецификация. позволяют некоторую свободу, поэтому реализации различаются. Очень безопасная реализация заключается в том, чтобы каждый раз выпускать новый токен обновления и аннулировать старый. Но это создает проблемы с одновременными вызовами (например, многопоточными приложениями). Итак, на некоторых серверах есть только один долговечный токен обновления (простая реализация, менее безопасный). Другие поддерживают старый токен обновления в течение короткого времени (например, 2 мин) после выпуска нового токена обновления.