Предоставляет ли OAuth 2.0 Access Token информацию на сервер ресурсов о запрашивающем клиенте?

Question

Как только клиент OAuth 2.0 получает непрозрачный токен доступа с сервера авторизации, он может использовать его в качестве токена-носителя для запроса данных с сервера ресурсов. Стандарт OAuth не определяет формат для токена доступа, но https://tools.ietf.org/html/rfc7662#section -2.2 определяет конечную точку самоконтроля токена, которая позволяет серверу ресурсов запрашивать дополнительную информацию о токене (и проверять ее).

Согласно спецификации, единственное обязательное поле в ответе конечной точки самоанализа - это логическое значение с именем "active". Так не обязательно ли для сервера авторизации предоставлять какую-либо информацию о субъекте или клиенте, которому был выдан токен? Оба описываются как необязательные в РФ C. Я знаю, что многие реализации сервера авторизации OAuth 2.0 используют JWT в качестве токенов доступа, и некоторые из них добавляют утверждение "azp" (которое определено в Open ID Connect spe c), но это не определяется OAuth spe c, что означает, что я не могу предположить, что все Серверы авторизации реализуют это таким образом. Интересно, какие еще опции должен знать сервер ресурсов, от какого клиента исходит запрос. Это зависит от конкретной реализации * сервера авторизации c? Существуют ли другие подходы, кроме утверждения "azp" или поля client_id в ответе на самоанализ?

Answer 1

Ответ на ваш вопрос в вашем предположении Я не могу предположить, что все Серверы авторизации реализуют его таким образом

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

Во-вторых, задайте этот вопрос себе, разрешаете ли вы интегрировать ваш продукт из токенов, созданных с неизвестного сервера авторизации? Например, вы можете принимать токены доступа со своего внутреннего сервера авторизации ИЛИ Azure токены в облачной среде. В обоих случаях у вас есть понимание формата токена, возможностей сервера авторизации. Таким образом, вы всегда будете программировать с учетом этого.

В настоящее время известные реализации авторизации поддерживают токены доступа JWT. Также у многих реализован самоанализ токенов. Таким образом, вы должны полагаться на эти методы, которые уже созданы в промышленности.

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