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