Эта страница переведена с помощью Cloud Translation API.

Использование сторонних токенов OAuth

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

В этой теме мы обсудим, как импортировать сгенерированные извне токены доступа, токены обновления или коды авторизации в хранилище токенов Edge. Этот метод можно использовать, если вы хотите настроить Apigee Edge для проверки токенов, сгенерированных вне Apigee Edge.

В обычном случае Apigee Edge генерирует и сохраняет токен OAuth и возвращает его вызывающему приложению. Затем вызывающее приложение предоставляет этот токен обратно Apigee Edge при запросе сервиса, и Apigee Edge — через политику OAuthV2 с параметром Operation = VerifyAccessToken — проверяет действительность токена. В этом разделе описывается, как настроить Apigee Edge для хранения токена OAuth, сгенерированного в другом месте, сохраняя при этом процесс проверки токена таким же, как если бы токен был сгенерирован самим Edge.

Пример

Если вы хотите увидеть работающий пример, иллюстрирующий описанную в этой теме технику, ознакомьтесь с примером Apigee Delegated Token Management .

Что это?

Предположим, у вас уже есть система авторизации, и вы хотите использовать токены или коды, сгенерированные этой системой, вместо токенов или кодов OAuth2, генерируемых Edge. Затем вы можете отправлять защищенные запросы к API-прокси с подставленными токенами или кодами, и Edge будет проверять их так, как если бы они были сгенерированы самим Edge.

Некоторая предыстория

В обычном случае Apigee Edge генерирует токен, создавая случайную строку букв и цифр. Apigee Edge связывает с этим токеном другие данные, такие как время выдачи токена, срок действия, список продуктов API, для которых токен действителен, и область действия. Вся эта информация может быть возвращена в ответе, автоматически генерируемом политикой OAuthV2, настроенной с параметром Operation = GenerateAccessToken. Ответ выглядит следующим образом:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

Значение атрибута access_token фактически является ключом поиска для данных ответа. Приложение может отправить запрос к API-прокси, размещенному в Edge, с токеном носителя zBC90HhCGmGlaMBWeZAai2s3za5j , и Edge — с политикой OAuthV2 с Operation = VerifyAccessToken — найдет токен, получит всю информацию и использует эту информацию для определения того, действителен ли токен для запрошенного API-прокси. Это называется проверкой токена. Вся вышеуказанная информация составляет токен. Значение access_token — это просто способ найти эту информацию.

С другой стороны, следуя описанным здесь шагам, вы можете настроить Edge для хранения токена таким образом, чтобы его значение access_token было сгенерировано внешней службой. Все остальные метаданные могут оставаться неизменными. Например, предположим, у вас есть внешняя система по отношению к Apigee Edge, которая генерирует токены вида "TOKEN-< 16 случайных чисел >". В этом случае полные метаданные токена, хранящиеся в Apigee Edge, могут выглядеть следующим образом:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

В этом случае приложение может отправить запрос к API-прокси, размещенному в Edge, с токеном носителя TOKEN-1092837373654221 , и Edge — через политику OAuthV2 с параметром Operation = VerifyAccessToken — сможет его проверить. Аналогичный шаблон импорта можно применить к кодам авторизации и токенам обновления.

Давайте поговорим о проверке учетных данных клиента.

Одним из предварительных условий для генерации токена является проверка запрашивающего клиента. По умолчанию политика OAuthV2/GenerateAccessToken в Apigee Edge неявно проверяет учетные данные клиента. Обычно в запросе на получение токена OAuthV2 client_id и client_secret передаются в заголовке Authorization, закодированном с помощью HTTP Basic Authorization (с объединением двоеточий и последующим кодированием в base64). Политика OAuthV2/GenerateAccessToken в Apigee Edge декодирует этот заголовок, находит client_id и проверяет, что переданный client_secret действителен для этого client_id. Это работает, если учетные данные известны Apigee Edge — другими словами, в Apigee Edge хранится приложение разработчика, содержащее учетные данные, которые, в свою очередь, содержат заданные client_id и client_secret.

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

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

Если вы хотите, чтобы политика OAuthV2/GenerateAccessToken в Apigee Edge проверяла учетные данные клиента в хранилище Edge, установите элемент <ExternalAuthorization> в значение false в конфигурации политики или полностью опустите его. Если вы хотите использовать внешнюю службу авторизации для явной проверки учетных данных клиента, установите <ExternalAuthorization> в true .

Хотя Apigee Edge может и не проверять учетные данные клиента, необходимо, чтобы client_id был известен и управлялся Apigee Edge. Каждый access_token в Apigee Edge, независимо от того, сгенерирован ли он Apigee Edge или внешней системой и затем импортирован в Apigee Edge, должен быть связан с клиентским приложением, что указывается client_id. Таким образом, даже в случае, если политика OAuthV2/GenerateAccessToken в Apigee Edge не проверит совпадение client_id и client_secret, она проверит, что client_id действителен, присутствует и не отозван. Поэтому в качестве предварительного шага настройки вам может потребоваться импортировать client_id через административный API Edge.

Схема обработки запросов OAuth от сторонних сервисов в Apigee

Для использования токенов из сторонних систем OAuth в Apigee Edge процесс генерации токенов доступа должен соответствовать одному из следующих шаблонов.

Внешняя проверка учетных данных клиента

Вызов сервиса для проверки входящих учетных данных клиента и получения внешнего токена.
Используйте функцию ExtractVariables или шаг JavaScript для извлечения сгенерированного извне токена из ответа.
Метод AssignMessage устанавливает специальную общеизвестную переменную oauth_external_authorization_status . Ее значение должно быть true, чтобы указать на действительность учетных данных клиента.
OAuthV2 /GenerateAccessToken с элементом <ExternalAuthorization> , установленным в true , и как минимум одним из элементов <ExternalAccessToken> , <ExternalRefreshToken> или <ExternalAuthorizationCode> .

Внутренняя проверка учетных данных клиента

Для получения внешнего токена используйте вызов сервиса .
Используйте функцию ExtractVariables или шаг JavaScript для извлечения сгенерированного извне токена из ответа.
OAuthV2 /GenerateAccessToken с элементом <ExternalAuthorization> , установленным в false , и как минимум одним из элементов <ExternalAccessToken> , <ExternalRefreshToken> или <ExternalAuthorizationCode> .

Примечания к настройке потока данных и политики.

Если вы хотите использовать внешнюю систему для проверки учетных данных клиента, вам необходимо разработать поток политик, который будет выполнять необходимые действия. Обычно для отправки распознанных извне учетных данных во внешнюю службу аутентификации используется политика ServiceCallout. Внешняя служба аутентификации, как правило, возвращает ответ и, если учетные данные действительны, также токен доступа.
После вызова ServiceCallout API-прокси должен проанализировать ответ, чтобы извлечь статус действительности, а также сгенерированный извне access_token и, возможно, refresh_token.
В политике OAuthV2/GenerateAccessToken установите для элемента <StoreToken> значение true , а для элемента <ExternalAuthorization> — значение true или false в зависимости от ситуации.
При выполнении политики OAuthV2/GenerateAccessToken считывается переменная oauth_external_authorization_status . Если переменная установлена и её значение равно true, Apigee Edge не пытается проверить учетные данные клиента. Если переменная не установлена или её значение не равно true, Apigee Edge попытается проверить учетные данные клиента.
В политике OAuthV2 есть три элемента, позволяющие указать внешние данные для импорта: <ExternalAccessToken> , <ExternalRefreshToken> и <ExternalAuthorizationCode> . Каждый из этих элементов принимает переменную потока . Политика Edge будет считывать эту переменную, чтобы найти сгенерированный извне токен доступа, токен обновления или код авторизации. Вам предстоит реализовать политики и логику для размещения внешних токенов или кодов в соответствующих переменных.
Например, следующая конфигурация в политике OAuthV2 указывает Edge искать токен в контекстной переменной с именем external_token .
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Вам также потребуется выполнить предыдущий шаг, который устанавливает эту переменную.
Что касается установки переменной oauth_external_authorization_status , распространенный способ — использование политики AssignMessage с элементом AssignVariable, например, так:
```
<AssignMessage name="AssignMessage-SetVariable">
    <DisplayName>Assign Message - Set Variable</DisplayName>
    <AssignVariable>
        <Name>oauth_external_authorization_status</Name>
        <Value>true</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>
```
Помните, что эта политика должна предшествовать политике OAuthV2 с параметром Operation = GenerateAccessToken.

Пример политики OAuthV2

Следующая политика OAuthV2 генерирует токен доступа Apigee Edge при условии, что Edge находит значение токена в переменной потока external_access_token .

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

Обычно при использовании типа предоставления учетных данных клиента необходимо предоставить заголовок Basic Authentication с закодированными идентификатором клиента (Client ID) и секретным ключом клиента (Client Secret). Однако в данном случае этот заголовок предоставлять не нужно. Политика по-прежнему ожидает наличия client_id в запросе и будет его проверять. Edge ожидает, что client_id будет отправлен как часть данных формы запроса, например, в request.formparam.client_id .

Теоретически, этот шаблон можно применить с любой сторонней службой авторизации OAuth2.