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

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

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

Код авторизации — один из наиболее часто используемых типов предоставления OAuth 2.0. Поток кода авторизации представляет собой конфигурацию «трехстороннего OAuth». В этой конфигурации пользователь аутентифицирует себя на сервере ресурсов и дает приложению согласие на доступ к своим защищенным ресурсам, не разглашая имя пользователя и пароли клиентскому приложению.

Об этой теме

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

Видео

Посмотрите короткое видео, чтобы узнать, как использовать тип предоставления авторизации OAuth 2.0 для защиты ваших API.

Варианты использования

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

Пример кода

Полный рабочий пример реализации типа предоставления кода авторизации можно найти на Apigee Edge в репозитории api-platform-samples на GitHub. См. расширенный образец oauth в каталоге api-platform-samples/sample-proxies. Подробную информацию об образце см. в файле README .

Блок-схема

На следующей блок-схеме показан поток кода авторизации OAuth с Apigee Edge, выступающим в качестве сервера авторизации.

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

Шаги в коде авторизации

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

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

1. Пользователь инициирует поток

Когда приложению необходимо получить доступ к защищенным ресурсам пользователя с сервера ресурсов (например, к списку контактов на сайте социальной сети), оно отправляет вызов API в Apigee Edge, который проверяет идентификатор клиента и, если он действителен, перенаправляет браузер на страницу входа, где пользователь вводит свои учетные данные. Вызов API включает информацию, полученную клиентским приложением при регистрации: идентификатор клиента и URI перенаправления.

2. Пользователь вводит учетные данные

Теперь пользователь видит страницу входа, где его просят ввести свои учетные данные. Если вход успешен, переходим к следующему шагу.

3. Пользователь дает согласие

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

4. Приложение для входа отправляет запрос Apigee Edge.

Если вход и согласие прошли успешно, приложение для входа отправляет данные POST в конечную точку /authorizationcode Apigee Edge. Данные включают в себя URI перенаправления, идентификатор клиента, область действия, любую информацию о пользователе, которую он желает включить, а также указание на успешный вход в систему.

5. Apigee Edge генерирует код авторизации.

Когда Edge получает запрос GET от приложения входа в систему на своей конечной точке /authorizationcode, происходят две вещи. Сначала Edge определяет, что вход в систему прошел успешно (путем проверки статуса HTTP или каким-либо другим способом). Next Edge проверяет, соответствует ли URI перенаправления, отправленный из приложения для входа в систему, URI перенаправления, который был указан при регистрации приложения в Apigee Edge. Если все в порядке, Edge генерирует код авторизации. Например:

http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

6. Edge отправляет код авторизации обратно клиенту.

Edge отправляет клиенту перенаправление 302 с кодом аутентификации, прикрепленным в качестве параметра запроса.

7. Клиент получает код авторизации и запрашивает код доступа у Edge.

Теперь, имея действительный код аутентификации, клиент может запросить токен доступа у Edge. Это делается путем отправки POST идентификатора клиента и секретных ключей клиента (полученных при регистрации приложения в Edge), типа предоставления и области действия. Включив идентификатор клиента и секретные ключи, Apigee Edge может проверить, является ли клиентское приложение зарегистрированным. Например:

$ curl https://{org_name}-test.apigee.net/my_oauth_proxy/accesstoken?code=Xyz123&grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpKNhGar6K&client_secret=hAr4GngA9vAyvI4'

8. Клиент получает токен доступа

Если все прошло успешно, Edge возвращает клиенту токен доступа. Токен доступа будет иметь срок действия и будет действителен только для области, указанной пользователем, когда он дал согласие приложению на доступ к своим ресурсам.

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

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

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

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

В качестве сервера авторизации Edge должен обрабатывать ряд запросов OAuth: для токенов доступа, кодов аутентификации, токенов обновления, перенаправления страниц входа и т. д. Для настройки этих конечных точек необходимо выполнить два основных шага:

Создание пользовательских потоков
Добавление и настройка политик OAuthV2

Пользовательская конфигурация потока

Обычно вы настраиваете этот поток типа гранта так, чтобы каждый шаг или «ветвь» потока определялся потоком в прокси-сервере Apigee Edge. Каждый поток имеет конечную точку и политику, которая выполняет необходимую задачу, специфичную для OAuth, например генерацию кода авторизации или токена доступа. Например, как показано в приведенном ниже XML-коде, конечная точка /oauth/authorizationcode имеет связанную политику GenerateAuthCode (которая представляет собой политику OAuthV2 с указанной операцией GenerateAuthorizationCode).

Самый простой способ показать конфигурацию потока — это пример XML. Информацию о каждом потоке смотрите во встроенных комментариях. Это пример: имена потоков и путей можно настроить по своему усмотрению. См. также раздел Настройка конечных точек и политик OAuth для краткого обзора шагов, необходимых для создания такого настраиваемого потока.

См. также пример реализации на GitHub.

<Flows>
  <Flow name="RedirectToLoginApp">
         <!-- 
         Publish this URI to developers to use for their 'login' link 
         -->
    <Condition>proxy.pathsuffix == "/oauth/authorize"</Condition>
    <Request>
        <Step><Name>RedirectToLoginPage</Name></Step>
    </Request>
  </Flow>
  <Flow name="GetAuthCode">
         <!-- 
         Call this URL from your Login app after you authenticate the user.
         The policy will automatically return the auth code in the response to the 
         redirect_uri registered by the calling app 
         -->
    <Condition>proxy.pathsuffix == "/oauth/authorizationcode"</Condition>
    <Request>
        <Step><Name>GenerateAuthCode</Name></Step>
    </Request>
  </Flow>
  <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>GenerateAccessToken</Name></Step>
    </Request>
  </Flow>
</Flows>

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

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

Это путь /oauth/authorize . Прикрепленная политика отвечает за перенаправление пользователя в приложение для входа, где конечный пользователь может безопасно аутентифицироваться и авторизовать клиентское приложение для доступа к своим защищенным ресурсам, не разглашая свое имя пользователя и пароль клиентскому приложению. Этого можно добиться с помощью политики вызова служб, JavaScript, Node.js или других средств.

Вызов API для выполнения запроса представляет собой GET и требует параметров запроса client_id, response_type, redirect_uri, области и состояния.

$ curl http://myorg-test.apigee.net/oauth/authorize?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

Рекомендация: приложение для входа обычно отправляет POST ответ на перенаправление обратно в Apigee Edge. Затем Edge направляет браузер пользователя на зарегистрированный URL-адрес обратного вызова. Рекомендуется не отправлять ответ непосредственно обратно пользовательскому агенту/клиенту, чтобы избежать раскрытия конфиденциальной информации. URL-адрес обратного вызова определяется при регистрации приложения на портале разработчика или при использовании API.

Получить код авторизации

Это путь /oauth/authorizationcode . Он использует политику OAuthV2 с указанной операцией GenerateAuthorizationCode.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GetAuthCode">
    <DisplayName>GetAuthCode</DisplayName>
    <Operation>GenerateAuthorizationCode</Operation>
    <ExpiresIn>600000</ExpiresIn>
    <GenerateResponse/>
</OAuthV2>

Вызов API для получения кода авторизации представляет собой GET и требует параметров запроса client_id, response_type и, при необходимости, области и состояния, как показано в этом примере:

$curl http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&scope=scope1%20scope2&state={some_string}

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

Эта политика привязана к пути /oauth/accesstoken . Он использует политику OAuthV2 с указанной операцией GenerateAccessCode. В этом случае параметрgrant_type ожидается как параметр запроса:

<OAuthV2 name="GetAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>360000000</ExpiresIn> 
    <SupportedGrantTypes> 
        <GrantType>authorization_code</GrantType> 
    </SupportedGrantTypes> 
    <GrantType>request.queryparam.grant_type</GrantType> 
    <GenerateResponse/> 
</OAuthV2>

Вызов API для получения кода доступа представляет собой POST и должен включать client_id, client_secret,grant_type=authorization_code и, необязательно, область. Например:

$ curl https://{org_name}-test.apigee.net/oauth/accesstoken?grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'

Это всего лишь базовое резюме. Рабочий пример включает в себя множество других политик для создания URL-адресов, выполнения преобразований и выполнения других задач. Полный рабочий проект можно найти в образце на GitHub.

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

Прикрепите политику VerifyAccessToken (политика OAuthV2 с указанной операцией VerifyAccessToken) к началу любого потока, который обращается к защищенному API, чтобы он выполнялся всякий раз, когда поступает запрос на защищенные ресурсы. 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

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