Как серверы 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 ?
Аннулирование маркеров доступа
Вы не можете аннулировать все маркеры доступа для определенного client_id . Client_id обычно привязан к одному приложению, но это приложение используется большим количеством пользователей. И даже один пользователь может использовать одно и то же приложение с разных устройств. Маркер обновления создает своего рода сеанс - он должен быть уникальным для конкретного приложения, пользователя и устройства. Более того,клиент может вызвать токен обновления с более узкой областью действия, и в этом случае вы не хотите аннулировать старый токен доступа с более широкой областью действия - клиент все еще может его использовать.
С моим ограниченным опытом серверы OAuth не аннулируют токены доступа при вызове токена обновления. Токены доступа недолговечны, они просто истекают вовремя.
Несколько запросов токена обновления
См. RFC6819, раздел 6 : Сервер авторизации МОЖЕТ выдать новый токен обновления ... Сервер авторизации МОЖЕТ отозвать старый токен обновления после выдачи нового обновления токен клиенту. Спецификация. позволяют некоторую свободу, поэтому реализации различаются. Очень безопасная реализация заключается в том, чтобы каждый раз выпускать новый токен обновления и аннулировать старый. Но это создает проблемы с одновременными вызовами (например, многопоточными приложениями). Итак, на некоторых серверах есть только один долговечный токен обновления (простая реализация, менее безопасный). Другие поддерживают старый токен обновления в течение короткого времени (например, 2 мин) после выпуска нового токена обновления.