Почему у OAuth v2 есть токены доступа и обновления?

Question

Раздел 4.2 проекта протокола OAuth 2.0 указывает, что сервер авторизации может возвращать как access_token (который используется для аутентификации себя с помощью ресурса), так и refresh_token, который используется исключительно для создания нового access_token

https://tools.ietf.org/html/rfc6749#section-4.2

Почему у обоих? Почему бы просто не заставить access_token длиться столько же, сколько refresh_token и не иметь refresh_token?

Answer 1

Пока токен обновления сохраняется сервером авторизации. Токен доступа является автономным, поэтому сервер ресурсов может проверить его, не сохраняя его, что экономит усилия поиска в случае проверки. Еще один момент, отсутствующий в обсуждении, от rfc6749 # page-55

"Например, сервер авторизации может использовать токен обновления ротация, при которой новый токен обновления выдается при каждом доступе ответ обновления токена. Предыдущий токен обновления недействителен, но сохраняется сервером авторизации. Если токен обновления скомпрометированы и впоследствии использованы как злоумышленником, так и законный клиент, один из них представит недействительное обновление токен, который сообщит серверу авторизации о взломе. "

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

Answer 2

Сначала клиент аутентифицируется на сервере авторизации, предоставляя разрешение на авторизацию.

Затем клиент запрашивает у сервера ресурсов защищенный ресурс, предоставляя маркер доступа.

Сервер ресурсов проверяет токен доступа и предоставляет защищенный ресурс.

Клиент отправляет запрос защищенного ресурса на сервер ресурсов, предоставляя токен доступа, где сервер ресурсов проверяет его и обрабатывает запрос, если он действителен,Этот шаг повторяется до тех пор, пока не истечет срок действия токена доступа.

Если срок действия токена доступа истечет, клиент аутентифицируется на сервере авторизации и запрашивает новый токен доступа, предоставляя токен обновления.Если токен доступа недействителен, сервер ресурсов отправляет обратно неверный ответ об ошибке токена клиенту.

Клиент аутентифицируется на сервере авторизации, предоставляя токен обновления.

Затем сервер авторизациипроверяет токен обновления путем аутентификации клиента и выдает новый токен доступа, если он действителен.

Answer 3

Давайте рассмотрим систему, в которой каждый пользователь связан с одной или несколькими ролями, а каждая роль связана с одной или несколькими привилегиями доступа.Эта информация может быть кэширована для лучшей производительности API.Но тогда могут быть изменения в конфигурации пользователя и роли (например, может быть предоставлен новый доступ или текущий доступ может быть отозван), и они должны быть отражены в кеше.

Мы можем использовать токены доступа и обновлятьдля такой цели.Когда API вызывается с токеном доступа, сервер ресурсов проверяет кэш на наличие прав доступа.Если есть какие-либо новые права доступа, это не отражается сразу.Когда срок действия маркера доступа истекает (скажем, через 30 минут), и клиент использует токен обновления для создания нового токена доступа, кэш можно обновить, обновив информацию о правах доступа пользователя из БД.

Другими словами, мы можем перемещать дорогостоящие операции из каждого вызова API, используя токены доступа, в событие генерации токена доступа, используя токен обновления.