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

Как реализовать тип предоставления пароля

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

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

Об этой теме

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

Примеры, которые могут быть вам полезны

Запрос токена доступа: тип предоставления пароля. В этом разделе рассказывается, как сформировать запрос токена, настроить правило OAuthV2 для типа предоставления пароля и настроить конечную точку для правила в Edge.
oauth-validate-key-secret – пример прокси-сервера на GitHub, который можно развернуть в Edge и протестировать. Это полный пример, в котором используется тип предоставления пароля. В нем показано, как правильно аутентифицировать учетные данные клиентского приложения (ключ/секрет), прежде чем отправлять учетные данные пользователя поставщику идентификационной информации.

Видео

Видео. Посмотрите видео о том, как реализовать тип предоставления пароля.

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

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

Блок-схема

На приведенной ниже диаграмме показан поток предоставления пароля владельца ресурса с Apigee Edge в качестве сервера авторизации.

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

Этапы процесса с типом предоставления пароля

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

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

1. Пользователь инициирует процесс и вводит учетные данные.

Когда приложению требуется доступ к защищенным ресурсам пользователя (например, когда пользователь нажимает кнопку в приложении), он перенаправляется на форму входа.

2. Приложение запрашивает маркер доступа у Apigee Edge

Приложение отправляет запрос на получение токена доступа, включая учетные данные пользователя, в конечную точку GenerateAccessToken в Apigee Edge.

Ниже приведен пример запроса POST, в котором указаны обязательные параметры для этого типа авторизации:

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

Также можно использовать следующую команду, в которой параметр -u в curl создает заголовок базовой аутентификации с кодировкой Base64.

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

(Каждая из этих команд должна быть указана в одной строке.)

Учетные данные пользователя содержатся в параметрах формы, а учетные данные клиента закодированы в заголовке базовой аутентификации HTTP. Подробное описание этого вызова API, в том числе сведения о необходимом заголовке Basic Auth, можно найти в разделе "Предоставление пароля" статьи Как запросить токены доступа и коды авторизации.

3. Edge проверяет клиентское приложение

Прежде чем отправлять имя пользователя и пароль поставщику идентификационной информации, Edge должен убедиться, что клиентское приложение, отправляющее запрос, является действительным и надежным. Один из способов сделать это – использовать аутентификацию по ключу API при вызове API. В некоторых случаях может потребоваться проверить и ключ клиента, и секретный код. Пример прокси-сервера, который демонстрирует этот альтернативный метод, можно найти в репозитории api-platform-samples на GitHub.

4. Edge обрабатывает учетные данные для входа

После проверки клиентского приложения вы можете использовать правило Service Callout или JavaScript, чтобы вызвать сервис идентификации и отправить учетные данные пользователя. Например, это может быть сервис LDAP или любой другой сервис, который вы хотите использовать для проверки учетных данных. Подробнее об этих правилах можно узнать в статьях Правила извлечения переменных и Правила JavaScript.

Если сервис идентификации подтверждает учетные данные и возвращает ответ 200, Edge продолжает обработку запроса. В противном случае Edge прекращает обработку и возвращает клиенту ошибку.

5. Выполняется правило OAuthV2.

Если учетные данные действительны, следующим шагом обработки будет выполнение правила OAuthV2, настроенного для типа предоставления пароля. Вот пример: Элементы <UserName> и <PassWord> являются обязательными. Их можно получить из переменных потока, сохраненных с помощью правила ExtractVariables. Подробную справочную информацию об этих правилах можно найти в разделе Правила OAuthV2.

<OAuthV2 name="GetAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>360000000</ExpiresIn> 
  <SupportedGrantTypes> 
     <GrantType>password</GrantType> 
  </SupportedGrantTypes> 
  <GrantType>request.queryparam.grant_type</GrantType> 
  <UserName>login</UserName>
  <PassWord>password</PassWord>
  <GenerateResponse/> 
</OAuthV2>

Если правило выполнено успешно, клиенту отправляется ответ, содержащий токен доступа. Ответ будет в формате JSON. Вот пример. Обратите внимание, что access_token – один из элементов:

{
    "issued_at": "1420258685042",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420258685042",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799",
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
    "organization_name": "docs",
    "refresh_token_expires_in": "0",
    "refresh_count": "0"
}

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

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

$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282