Эта страница переведена с помощью 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 на основе идентификатора конечного пользователя или идентификатора приложения.

Вы можете использовать вызов Get Permission для вызова Resource 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
Используйте переменную потока, предоставляющую идентификатор конечного пользователя.