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

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

Darcy Ye

Developer

9/23/2024

Хватит тратить недели на аутентификацию пользователей

Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.

Начать

Инспекция токена 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 токен доступа.

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

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

Авторизация с использованием токена доступа.

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

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

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

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

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

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

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

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

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

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

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