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

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

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

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

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

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

{
  "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 заполняет набор контекстных переменных, содержащих информацию о токене. К ним относятся:

  • Название организации
  • разработчик.id
  • имя разработчика.приложения
  • ID клиента
  • тип_гранта
  • token_type
  • access_token
  • выпущено_в
  • expires_in //--в секундах
  • положение дел
  • объем
  • apiproduct.name*

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

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

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

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

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

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