Чтобы переводить контент на ваш предпочитаемый язык, Google использует технологии на основе искусственного интеллекта. Переводы от ИИ могут содержать ошибки.

Как использовать сторонние токены 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.

"Что это?"

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

Немного о классификации

В обычном случае Apigee Edge генерирует токен, создавая случайную строку из букв и цифр. Apigee Edge связывает с этим токеном другие данные, например время выдачи токена, срок его действия, список продуктов API, для которых действителен токен, и область действия. Вся эта информация может быть возвращена в ответе, автоматически сгенерированном правилом OAuthV2, настроенным с помощью операции 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 которого генерируется внешним сервисом. Остальные метаданные могут быть одинаковыми. Предположим, у вас есть внешняя система, которая генерирует токены в формате "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 (объединение через двоеточие, а затем кодирование 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. Каждый токен доступа в 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. Значение должно быть true, чтобы указать, что учетные данные клиента действительны.
OAuthV2/GenerateAccessToken с элементом <ExternalAuthorization>, для которого задано значение true, и хотя бы одним из элементов <ExternalAccessToken>, <ExternalRefreshToken> или <ExternalAuthorizationCode>.

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

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

Примечания о конфигурации потока и правил

Если вы хотите использовать внешнюю систему для проверки учетных данных клиента, вам нужно самостоятельно разработать правила, которые будут выполнять необходимые действия. Обычно для отправки внешних учетных данных во внешний сервис аутентификации используется правило ServiceCallout. Внешний сервис аутентификации обычно возвращает ответ, а если учетные данные действительны, то и токен доступа.
После вызова ServiceCallout прокси-сервер API должен проанализировать ответ, чтобы извлечь статус действительности, а также внешний токен доступа и, возможно, токен обновления.
В правиле 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>

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

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