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