Вы просматриваете документацию по 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 .