Эта страница переведена с помощью Cloud Translation API.

Включить получение и отзыв токенов доступа OAuth 2.0 по идентификатору конечного пользователя, идентификатору приложения или по тому и другому.

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

В этом разделе описывается, как включить получение и отзыв токенов доступа 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, которые выполняют эти извлечения и отзыва, см. следующие смарт-документы:

Включение доступа к токенам OAuth 2.0 по идентификатору пользователя и идентификатору приложения.

Способ включения доступа к токенам OAuth 2.0 по идентификатору пользователя и идентификатору приложения зависит от того, как вы развернули Edge:

Облачное развертывание
Облачное развертывание Edge означает, что большая часть конфигурации выполняется Apigee. Вы несете ответственность только за настройку политики OAuth 2.0 для добавления идентификатора пользователя в токен доступа. Подробнее см. процедуру ниже.
Edge для развертывания частного облака
В Apigee Edge для частного облака (локальная версия) вы несете полную ответственность за настройку. Дополнительную информацию см. в разделе «Эксплуатация и настройка» .
Апигей гибридный
Доступ к токенам OAuth 2.0 по идентификатору пользователя включен по умолчанию. Вы несете ответственность только за настройку политики OAuth 2.0 для добавления идентификатора пользователя в токен доступа. Дополнительную информацию см. в шаге 5 процедуры ниже.

Включение доступа в облаке

Шаг 1. Разрешите организации поддерживать эту функцию.

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

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

Шаг 2. Предоставьте разрешения на ресурсы oauth2 ролям opsadmin и orgadmin.

Только вашим ролям orgadmin и opsadmin должны быть предоставлены разрешения на получение ( get ) и отзыв ( put ) вызовов ресурса oauth2 на основе идентификатора конечного пользователя или идентификатора приложения.

Вы можете использовать вызов API «Получить разрешение для ресурса», чтобы узнать, какие роли имеют разрешения get и put для ресурса oauth2 .

Если вам нужно добавить или удалить какие-либо разрешения, обратитесь в службу поддержки Apigee Edge , чтобы они выполнили обновления.

Шаг 3. Скопируйте существующие токены доступа OAuth 2.0 на узлы Cassandra.

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

Шаг 4. Добавьте свойство oauth_max_search_limit на сервер управления и обработчик сообщений.

В этой задаче файлы keymanagement.properties для вашего сервера управления и обработчика сообщений будут обновлены и будут включать это свойство: oauth_max_search_limit = 100 . 100 — рекомендуемое значение Apigee, но его можно установить по своему усмотрению.

Свяжитесь со службой поддержки Apigee Edge , чтобы они сделали это дополнение.

Шаг 5. Настройте политику 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.
Используйте переменную потока, предоставляющую идентификатор конечного пользователя.