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

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

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

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

По этой теме

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

Видео

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

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

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

Пример кода

Полную, работающую реализацию типа предоставления кода авторизации в Apigee Edge можно найти в репозитории api-platform-samples на GitHub. См. пример oauth-advanced в каталоге 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 получает POST-запрос от приложения авторизации на своей конечной точке /authorizationcode, происходят две вещи. Во-первых, Edge определяет, что авторизация прошла успешно (проверяя параметры запроса или заголовки на наличие индикатора успеха). Во-вторых, Edge проверяет, совпадает ли URI перенаправления, отправленный приложением авторизации, с URI перенаправления, указанным при регистрации приложения в Apigee Edge. Если все в порядке, Edge генерирует код авторизации.

{redirect_uri}?code={authorization_code}&state={some_string}

6. Клиент получает код авторизации и запрашивает токен доступа у 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'

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

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

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

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

$ 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, scope и state.

$ 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-запрос выполняется методом POST и требует передачи в теле запроса в качестве параметров формы следующих параметров: client_id, response_type, redirect_uri, а также, при необходимости, scope и state, как показано в этом примере:

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

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

Эта политика привязана к пути /oauth/accesstoken . Она использует политику OAuthV2 с указанной операцией GenerateAccessToken. В этом случае параметр 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 и, при необходимости, scope. Например:

$ curl https://{org_name}-test.apigee.net/oauth/accesstoken?grant_type=authorization_code -X POST -d 'code={authorization_code}&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, необходимо предоставить действительный токен доступа. Правильный шаблон — включить токен в заголовок Authorization следующим образом: Обратите внимание, что токен доступа также называют «токеном носителя».

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

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