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

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

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

В этом разделе мы обсудим, как импортировать созданные извне токены доступа, токены обновления или коды аутентификации в хранилище токенов 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 передаются в заголовке авторизации, закодированном с помощью базовой авторизации HTTP (объединенном через двоеточие, затем в кодировке 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 может не проверять учетные данные клиента, Apigee Edge все равно необходимо, чтобы client_id был известен и управлялся им. Каждый 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, процесс создания токенов доступа должен следовать одному из следующих шаблонов.

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

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

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

ServiceCallout для получения внешнего токена.
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 не пытается проверить учетные данные клиента. Если переменная не установлена или ее значение неверно, 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>

Обычно при использовании типа предоставления учетных данных клиента необходимо предоставить заголовок базовой аутентификации с закодированным идентификатором клиента и секретом клиента. Однако в этом случае вам не нужно предоставлять этот заголовок. Политика по-прежнему ожидает, что client_id будет присутствовать в запросе, и политика проверит его. Edge ожидает, что client_id будет отправлен как часть данных формы запроса, например, в request.formparam.client_id .

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