Вы просматриваете документацию Apigee Edge .
Перейти к документации Apigee X. info
В этом разделе описывается, как включить извлечение и отзыв токенов доступа OAuth 2.0 по идентификатору конечного пользователя, идентификатору приложения или обоим. Функция идентификатора конечного пользователя требует специальной настройки, как описано в этой теме. Под конечным пользователем мы подразумеваем пользователя приложения, вызывающего API.
Когда следует включать доступ по идентификатору конечного пользователя
Иногда полезно хранить идентификатор пользователя в токене доступа. Включайте функцию доступа к идентификатору конечного пользователя только в том случае, если у вас есть хороший вариант использования для этого. Например:
- Функция для вашего веб-сайта или приложения, с помощью которой пользователи могут видеть, какие сторонние приложения они авторизовали, и предоставлять возможность отозвать доступ к этим приложениям.
- Функция, позволяющая авторизованному пользователю отозвать все токены доступа, связанные с определенным приложением разработчика.
О токенах доступа OAuth
Идентификаторы приложений автоматически добавляются в токен доступа OAuth. Поэтому после включения доступа к токену для организации, как описано ниже, вы можете отозвать токены доступа по идентификатору приложения.
Для извлечения и отзыва токенов доступа OAuth 2.0 по идентификатору конечного пользователя в токенах доступа должен присутствовать идентификатор конечного пользователя. Процедура ниже описывает, как добавить идентификатор конечного пользователя к существующему токену.
По умолчанию, когда Edge генерирует токен доступа OAuth 2.0, токен имеет формат, показанный ниже:
{ "issued_at" : "1421847736581", "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a", "scope" : "READ", "status" : "approved", "api_product_list" : "[PremiumWeatherAPI]", "expires_in" : "3599", //--in seconds "developer.email" : "tesla@weathersample.com", "organization_id" : "0", "token_type" : "BearerToken", "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP", "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL", "organization_name" : "myorg", "refresh_token_expires_in" : "0", //--in seconds "refresh_count" : "0" }
Обратите внимание на следующее:
- Поле application_name содержит UUID приложения, связанного с токеном. Если вы включаете извлечение и отзыв токенов доступа OAuth 2.0 по идентификатору приложения, то это идентификатор приложения, который вы используете.
- Поле access_token содержит значение токена доступа OAuth 2.0.
В токене доступа OAuth по умолчанию нет поля для идентификатора конечного пользователя. Чтобы включить извлечение и отзыв токенов доступа OAuth 2.0 по идентификатору конечного пользователя, необходимо настроить политику OAuth 2.0 для включения идентификатора пользователя в токен, как описано в процедуре ниже. Обратите внимание, что если вы хотите извлекать и отзывать токены доступа OAuth 2.0 только по идентификатору приложения, то нет необходимости включать доступ по идентификатору конечного пользователя.
Вы передаете идентификатор конечного пользователя в конечную точку создания токена. Вы можете передать идентификатор конечного пользователя как параметр запроса, параметр формы или в заголовке (как объясняется далее в этой теме). После настройки Edge для включения идентификатора конечного пользователя в токен, он включается как поле app_enduser , как показано ниже:
{ "issued_at" : "1421847736581", "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a", "scope" : "READ", "app_enduser" : "6ZG094fgnjNf02EK", "status" : "approved", "api_product_list" : "[PremiumWeatherAPI]", "expires_in" : "3599", //--in seconds "developer.email" : "tesla@weathersample.com", "organization_id" : "0", "token_type" : "BearerToken", "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP", "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL", "organization_name" : "myorg", "refresh_token_expires_in" : "0", //--in seconds "refresh_count" : "0" }
Чтобы узнать, как выполнять вызовы API, которые выполняют эти извлечения и отзыв, ознакомьтесь со следующими документами Smart Docs:
- Отзыв токена доступа OAuth2 по идентификатору конечного пользователя или приложения
- Получите токен доступа OAuth2 по идентификатору конечного пользователя или приложения
Включение доступа к токенам OAuth 2.0 по идентификатору пользователя и идентификатору приложения
Способ включения доступа к токенам OAuth 2.0 по идентификатору пользователя и идентификатору приложения зависит от того, как вы развернули Edge:
Развертывание на основе облака
Облачное развертывание Edge означает, что большая часть конфигурации обрабатывается Apigee. Вы несете ответственность только за настройку политики OAuth 2.0 для добавления идентификатора пользователя к токену доступа. Подробнее см. процедуру ниже.
Edge для развертывания частного облака
В Apigee Edge for Private Cloud (on-premises) вы полностью отвечаете за конфигурацию. Подробнее см. в разделе Операции и конфигурация .
гибрид Апиги
Доступ к токенам OAuth 2.0 по идентификатору пользователя включен по умолчанию. Вы несете ответственность только за настройку политики OAuth 2.0 для добавления идентификатора пользователя к токену доступа. Подробнее см. Шаг 5 процедуры ниже.
Обеспечение доступа в облаке
Шаг 1: Включите поддержку этой функции в организации
Эту функцию необходимо включить для каждой организации, в которой вы хотите ее поддерживать.
Обратитесь в службу поддержки Apigee Edge , чтобы они обновили вашу организацию.
Шаг 2: Предоставьте разрешения на доступ к ресурсам oauth2 ролям opsadmin и orgadmin
Только вашим ролям orgadmin и opsadmin должны быть предоставлены разрешения на выполнение вызовов извлечения ( get ) и отзыва ( put ) к ресурсу oauth2 на основе идентификатора конечного пользователя или идентификатора приложения.
Вы можете использовать вызов API Get Permission for a Resource, чтобы узнать, какие роли имеют разрешения get и put для ресурса oauth2 .
Если вам необходимо добавить или удалить какие-либо разрешения, обратитесь в службу поддержки Apigee Edge , чтобы они выполнили обновления.
Шаг 3: Скопируйте существующие токены доступа OAuth 2.0 на узлы Cassandra.
Выполняется службой поддержки Apigee : в этой задаче копии существующих токенов доступа OAuth 2.0 в затронутых организациях будут скопированы и сохранены в ваших узлах Cassandra. Эта процедура будет выполнена на узлах Cassandra для каждого из ваших модулей Apigee Edge. Это позволит API-вызовам извлечения и отзыва выполняться для всех ваших токенов доступа OAuth 2.0, существующих и вновь сгенерированных.
Шаг 4: Настройте политику OAuth 2.0 для генерации токенов доступа, включающих идентификаторы конечных пользователей.
Настройте политику OAuth 2.0, используемую для генерации токенов доступа, чтобы включить идентификатор конечного пользователя в токен. Включив идентификаторы конечных пользователей в токены доступа, вы сможете выполнять извлечения и отзыв по идентификатору конечного пользователя.
Чтобы настроить политику для включения идентификатора конечного пользователя в токен доступа, необходимо указать входную переменную, содержащую идентификатор конечного пользователя. Используйте тег <AppEndUser> для указания переменной.
Политика OAuth 2.0 ниже, названная GenerateAccessTokenClient , генерирует токен доступа OAuth 2.0. Обратите внимание на добавление тега <AppEndUser> , выделенного жирным шрифтом:
<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessTokenClient"> <DisplayName>OAuth 2.0.0 1</DisplayName> <ExternalAuthorization>false</ExternalAuthorization> <Operation>GenerateAccessToken</Operation> <SupportedGrantTypes> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <GenerateResponse enabled="true"/> <GrantType>request.queryparam.grant_type</GrantType> <AppEndUser>request.header.appuserID</AppEndUser> <ExpiresIn>960000</ExpiresIn> </OAuthV2>
Затем вы можете использовать следующую команду cURL для генерации токена доступа OAuth 2.0, передав идентификатор пользователя в качестве заголовка appuserID :
curl -H "appuserID:6ZG094fgnjNf02EK" / https://myorg-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials / -X POST / -d 'client_id=k3nJyFJIA3p62TKIkLO6OJNi87GYXFmP&client_secret=gk58jK5lIp943AY4'
В этом примере appuserID передается как заголовок запроса. Вы можете передавать информацию как часть запроса многими способами. Например, в качестве альтернативы вы можете:
- Используйте переменную параметра формы: request.formparam.appuserID
- Используйте переменную потока, предоставляющую идентификатор конечного пользователя.