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

Реализация типа предоставления пароля

Вы просматриваете документацию 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 для создания заголовка базовой аутентификации в кодировке 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 обрабатывает учетные данные для входа.

После проверки клиентского приложения вы можете использовать вызов службы или политику 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 на целевой сервер ресурсов. Токены доступа передаются в заголовке авторизации. Например:

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