Настройка токенов и кодов авторизации

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

О метаданных токена

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

Когда Edge генерирует эти артефакты OAuth, он также прикрепляет метаданные к токену или коду. Например, токен доступа связан с парами «имя/значение», которые определяют время истечения срока действия, связанное приложение и разработчика, а также другую информацию.

JSON-представление токена доступа Edge выглядит следующим образом:

{
  "issued_at" : "1372170159093",
  "application_name" : "ccd1803b-b557-4520-bd62-ddd3abf8e501",
  "scope" : "READ",
  "status" : "approved",
  "api_product_list" : "[Product1,Product2]",
  "api_product_list_json" : ["Product1", "Product2"],
  "expires_in" : "3599", //--in seconds
  "developer.email" : "joe@weathersample.com",
  "organization_id" : "0",
  "refresh_token" : "82XMXgDyHTpFyXOaApj8C2AGIPnN2IZe",
  "client_id" : "deAVedE0W9Z9U35PAMaAJYphBJCGdrND",
  "access_token" : "shTUmeI1geSKin0TODcGLXBNe9vp",
  "organization_name" : "apifactory",
  "refresh_count" : "0"
}

Добавление пользовательских атрибутов к токенам OAuth

Иногда бывает полезно добавить к токену доступа пользовательские метаданные. Например, вы можете захотеть добавить к токену имя пользователя, информацию о членстве в группах или ролях пользователя, идентификатор клиента, идентификатор сессии или другую произвольную информацию. В Apigee Edge эти данные называются «пользовательскими атрибутами». Впоследствии, когда токен проверяется в рамках запроса API, эти данные становятся доступны прокси-серверу API через контекстные переменные. Прокси-сервер API может принимать детальные решения об авторизации или маршрутизации на основе пользовательских данных, прикрепленных к токену.

Чтобы прикрепить к токену произвольные данные, используйте элемент <Attributes> в политике OAuthV2 . Вы можете указать имя пользовательского атрибута и его значение. Например, вот конфигурация политики, которая генерирует токен и прикрепляет к нему пользовательский атрибут с именем "tenant_list":

<OAuthV2 name="GenerateAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>600000</ExpiresIn>
  <GenerateResponse />
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <Attributes> 
    <Attribute name="tenant_list" ref="tenant_list_retrieved_from_external_service" display="false"/>
  </Attributes>
</OAuthV2>

Вы можете указать несколько пользовательских атрибутов и неявно привязать их либо к коду авторизации ( <Operation>GenerateAuthorizationCode</Operation> ), либо к токену ( <Operation>GenerateAccessToken</Operation> ) во время генерации.

Если display установлен в true (по умолчанию), пользовательские атрибуты возвращаются в ответе, где они могут быть видны приложению или переданы конечному пользователю. Если display установлен в false , пользовательские атрибуты хранятся в хранилище данных, но не возвращаются в ответном сообщении. В любом случае, пользовательские данные становятся доступны политикам в API-прокси после проверки токена.

Для получения дополнительной информации о параметре display «Отображение или скрытие пользовательских атрибутов в ответе» см. соответствующий раздел .

Получение пользовательских атрибутов во время выполнения

При вызове функции OAuthV2/VerifyAccessToken , Apigee Edge проверяет токен, находя его в хранилище токенов. Затем Apigee Edge заполняет набор контекстных переменных, содержащих информацию о токене. К ним относятся:

  • название_организации
  • developer.id
  • developer.app.name
  • client_id
  • grant_type
  • token_type
  • access_token
  • выпущено_в
  • expires_in //--в секундах
  • статус
  • объем
  • apiproduct.name*

Если токен содержит какие-либо пользовательские атрибуты, они становятся доступными в контекстной переменной с именем accesstoken.{custom_attribute} . Например, предположим, что токен выдан в соответствии с политикой, показанной выше. После проверки такого токена появится дополнительная контекстная переменная с именем accesstoken.tenant_list , содержащая значение, сохраненное на момент генерации токена.

Затем политики или условия могут ссылаться на эти переменные и изменять поведение в зависимости от хранящихся в них значений.

Настройка и обновление пользовательских атрибутов во время выполнения

В некоторых ситуациях может потребоваться, чтобы ваш API-прокси обновлял метаданные, связанные с токеном доступа, во время выполнения вызова API на Apigee Edge. Для этого Apigee предоставляет политики для получения и установки атрибутов токена. Дополнительную информацию см. в разделах «Политика получения информации OAuth V2» и «Политика установки информации OAuth V2» .

В каждой из этих политик элемент AccessToken должен ссылаться на переменную, содержащую токен доступа.

Вы также можете использовать API Edge для обновления пользовательских атрибутов, прикрепленных к токену. См. документацию по API для метода обновления токена доступа OAuth 2.0 .