Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info
При использовании типа предоставления учетных данных клиента приложение отправляет свои собственные учетные данные (идентификатор клиента и секретный ключ клиента) на конечную точку в 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. Клиент запрашивает токен доступа.
Для получения токена доступа клиент отправляет POST-запрос к 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 в качестве параметров запроса, как показано выше, рекомендуется передавать их в закодированной в 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 client_id + client + secret и параметром запроса 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 следующим образом: Обратите внимание, что токен доступа также называют «токеном носителя».
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
См. также Отправка токена доступа .
Дополнительные ресурсы
- Apigee предлагает онлайн-обучение для разработчиков API, включая курс по безопасности API , в том числе по OAuth.
- Политика OAuthV2 — содержит множество примеров, демонстрирующих, как отправлять запросы на сервер авторизации и как настраивать политику OAuthV2.