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

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

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

Чтобы получить токен доступа, клиент отправляет вызов API Edge со значениями идентификатора и секрета клиента, полученными из зарегистрированного приложения разработчика. Кроме того, параметр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 можно передавать в качестве параметров запроса, как показано выше, рекомендуется передавать их в виде строки URL-адреса в кодировке Base64 в заголовке авторизации. Для этого вам необходимо использовать инструмент или утилиту кодирования 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>

Настройка потока с помощью политики

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

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

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

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

Вызов API для получения токена доступа представляет собой POST и включает заголовок авторизации с кодировкой client_id + client+secret в кодировке 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, вам необходимо предоставить действительный токен доступа. Правильный шаблон — включить токен в заголовок авторизации следующим образом: Обратите внимание, что токен доступа также называется «токеном-носителем».

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

См. также Отправка токена доступа .

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

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