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

Реализация типа предоставления учетных данных клиента

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

При использовании типа предоставления учетных данных клиента приложение отправляет свои учетные данные (идентификатор клиента и секретный код клиента) в конечную точку Apigee Edge, настроенную для создания токена доступа. Если учетные данные действительны, Edge возвращает клиентскому приложению токен доступа.

Об этой теме

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

Примеры использования

Чаще всего этот тип используется, когда приложение также является владельцем ресурса. Например, приложению может потребоваться доступ к облачному хранилищу на сервере, чтобы сохранять и извлекать данные, которые оно использует для работы, а не данные, принадлежащие конечному пользователю. Этот тип предоставления доступа используется только для обмена данными между клиентским приложением и сервером авторизации. Конечный пользователь не участвует в этом процессе.

Роли

Роли определяют "действующих лиц", участвующих в процессе OAuth. Давайте рассмотрим роли учетных данных клиента, чтобы понять, как Apigee Edge вписывается в эту схему. Полное описание ролей OAuth 2.0 приведено в спецификации IETF OAuth 2.0.

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

Пример кода

Полный рабочий пример реализации типа предоставления учетных данных клиента можно найти на GitHub. Дополнительные примеры можно найти в разделе Дополнительные ресурсы ниже.

Блок-схема

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

Этапы процесса передачи учетных данных клиента

Ниже приведены основные шаги по реализации типа предоставления кода учетных данных клиента, в котором Apigee Edge выступает в качестве сервера авторизации. При этом клиентское приложение просто предоставляет свой идентификатор и секретный код, и если они действительны, Apigee Edge возвращает токен доступа.

Требование. Клиентское приложение должно быть зарегистрировано в Apigee Edge, чтобы получить идентификатор клиента и секретные ключи клиента. Подробнее о регистрации клиентских приложений…

1. Клиент запрашивает маркер доступа.

Чтобы получить токен доступа, клиент отправляет в Edge вызов API с помощью метода POST, указав идентификатор клиента и секретный код клиента, полученные из зарегистрированного приложения для разработчиков. Кроме того, параметр grant_type=client_credentials должен быть передан в качестве параметра запроса. (Однако вы можете настроить правило OAuthV2 так, чтобы этот параметр принимался в заголовке запроса или теле запроса. Подробнее о правиле OAuthV2…

Пример:

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials&client_id=ns4fQc14Zg4hKFCNaSzArVuwszX95X&client_secret=ZIjFyTsNgQNyxI'

Примечание. Хотя вы можете передавать значения client_id и client_secret в качестве параметров запроса, как показано выше, рекомендуется передавать их в виде строки, закодированной в формате Base64 URL, в заголовке Authorization. Для этого вам понадобится инструмент или утилита для кодирования Base64, чтобы закодировать оба значения вместе, разделив их двоеточием. Пример: aBase64EncodeFunction(clientidvalue:clientsecret). Таким образом, приведенный выше пример будет закодирован следующим образом:

result = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI) // Обратите внимание на двоеточие, разделяющее два значения.

Результат кодирования строки выше по алгоритму Base64: bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==

Затем отправьте запрос токена следующим образом:

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg=='

2. Edge проверяет учетные данные.

Обратите внимание, что вызов API отправляется в конечную точку /accesstoken. К этой конечной точке прикреплено правило, которое проверяет учетные данные приложения. То есть правило сравнивает отправленные ключи с теми, которые были созданы Apigee Edge при регистрации приложения. Если вы хотите узнать больше о конечных точках OAuth в Edge, ознакомьтесь со статьей Настройка конечных точек и правил OAuth.

3. Edge возвращает ответ

Если учетные данные действительны, Edge возвращает клиенту токен доступа. Если нет, возвращается ошибка.

4. Клиент вызывает защищенный API

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

Настройка процессов и правил

Как сервер авторизации Edge обрабатывает запросы на токены доступа. Как разработчику API, вам нужно создать прокси-сервер со специальным потоком для обработки запросов токенов, а также добавить и настроить правила OAuthV2. В этом разделе рассказывается, как настроить эту конечную точку.

Специальная конфигурация процесса

Самый простой способ показать, как настроен поток прокси-сервера API, – это привести определение потока в формате XML. Ниже приведен пример потока прокси-сервера API, предназначенного для обработки запроса токена доступа. Например, когда поступает запрос и суффикс пути соответствует /accesstoken, активируется правило GetAccessToken. Чтобы быстро ознакомиться с шагами, необходимыми для создания такого пользовательского потока, ознакомьтесь с разделом Настройка конечных точек и правил OAuth.

<Flows>
  <Flow name="GetAccessToken">
         <!-- This policy flow is triggered when the URI path suffix
         matches /oauth/accesstoken. Publish this URL to app developers 
         to use when obtaining an access token using an auth code   
         -->
    <Condition>proxy.pathsuffix == "/oauth/accesstoken"</Condition>
    <Request>
        <Step><Name>GetAccessToken</Name></Step>
    </Request>
  </Flow>
</Flows>

Как настроить процесс с помощью правила

Вам нужно прикрепить к конечной точке правила, как описано ниже. Краткий обзор шагов, необходимых для добавления правила OAuthV2 в конечную точку прокси, приведен в разделе Настройка конечных точек и правил OAuth.

Получить токен доступа

Это правило прикреплено к пути /accesstoken. Он использует правило OAuthV2 с указанной операцией GenerateAccessToken.

<OAuthV2 name="GetAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>3600000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GenerateResponse/>
</OAuthV2>

Вызов API для получения токена доступа выполняется с помощью метода POST и включает заголовок Authorization с закодированными в формате Base64 идентификатором и секретным кодом клиента, а также параметр запроса grant_type=client_credentials. Также можно добавить необязательные параметры для области действия и состояния. Пример:

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVgT1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'

Применение правила для проверки токена доступа

Чтобы защитить API с помощью OAuth 2.0, добавьте правило OAuthV2 с операцией VerifyAccessToken. Это правило проверяет, есть ли у входящих запросов действительный маркер доступа. Если токен действителен, Edge обрабатывает запрос. Если он недействителен, Edge возвращает ошибку. Основные шаги описаны в разделе Как проверить токены доступа.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
    <DisplayName>VerifyAccessToken</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <SupportedGrantTypes/>
    <GenerateResponse enabled="true"/>
    <Tokens/>
</OAuthV2>

Как вызвать защищенный API

Чтобы вызвать API, защищенный с помощью OAuth 2.0, вам потребуется действительный токен доступа. Правильный способ – включить токен в заголовок Authorization, как показано ниже. Обратите внимание, что токен доступа также называется токеном Bearer.

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Также ознакомьтесь с информацией о том, как отправлять токен доступа.

Дополнительные ресурсы

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