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

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

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

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

  • название_организации
  • разработчик.id
  • разработчик.приложение.имя
  • client_id
  • тип_гранта
  • тип токена
  • access_token
  • выдано_at
  • 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 .