Инспекция токена OAuth 2.0

Инспекция токена OAuth 2.0 определяет метод, который позволяет авторизованному защищенному ресурсу запрашивать сервер авторизации, чтобы определить метаданные, связанные с данным токеном (либо токеном доступа, либо токеном обновления), предоставленным клиентом OAuth. На основе метаданных конкретного токена это позволяет владельцу ресурса получить доступ к защищенному ресурсу.

Эти метаданные включают:

• Является ли токен в настоящее время активным (или если он истек или был отозван)
• Разрешения, которые предоставляет токен доступа (обычно передаются через области OAuth 2.0)
• Контекст авторизации, в котором был предоставлен токен (включая, кто авторизовал токен и какому клиенту он был выдан)

Инспекция токена позволяет защищенному ресурсу запрашивать эту информацию, независимо от того, содержится ли она в самом токене.

Существует два типа токенов доступа, в зависимости от того, как они закодированы:

• На основе идентификатора: Токен представляет собой случайный, труднодоступный идентификатор, связанный с авторизацией в базе данных сервера авторизации.
• Самодостаточный: Авторизация закодирована в самом токене и защищена с помощью криптографии для предотвращения подделки. JSON Web Token (JWT) является общим стандартом для этого метода.

Для самодостаточных токенов метаданные, связанные с авторизацией, могут быть непосредственно разобраны из токена доступа. Однако для токенов на основе идентификатора необходимо использовать функциональность инспекции токенов сервера авторизации для проверки/получения метаданных.

Запрос на инспекцию токена#

Использование токенов доступа на основе идентификатора требует проверки на сервере авторизации через сетевой запрос. Существует стандартный протокол для этого, называемый OAuth 2.0 Token Introspection (RFC 7662).

Защищенный ресурс отправит токен на конечную точку инспекции сервера авторизации методом POST, и в ответ получит JSON-объект, содержащий параметры токена.

Учтите, что запросы на инспекцию не могут быть инициированы произвольно; они должны соответствовать одному из следующих условий:

• Аутентификация с использованием учетных данных (которые должны быть предварительно зарегистрированы на сервере авторизации), или
• Авторизация с использованием токена доступа.

В результате, в этом конкретном взаимодействии защищенный ресурс становится клиентом OAuth, а сервер авторизации - защищенным ресурсом.

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

Ниже приведен пример запроса на инспекцию, который напрямую использует токен доступа. Токен доступа может быть получен непосредственно с конечной точки /token, используя учетные данные зарегистрированного приложения машина-к-машине и тип предоставления client_credentials.

Ответ на инспекцию токена#

Наиболее важным параметром является active, который является логическим значением. Если true, это указывает на то, что токен действителен, и JSON-объект будет включать другие детали токена, такие как значения области. Если false, токен либо недействителен, либо истек, и защищенный ресурс должен вернуть ответ 401 Unauthorized с кодом ошибки invalid_token.

Вот пример ответа для действительного токена:

Помимо active, который обязателен, все остальные параметры являются необязательными.

Защищенный ресурс может использовать эти дополнительные поля для определения разрешений на доступ, аналогично тому, как он разбирает и проверяет JWT токен доступа.