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

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

Вы просматриваете документацию по 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-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.

Если вход выполнен успешно и согласие получено, приложение для входа отправляет данные в конечную точку /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 токен доступа. Для этого он отправляет идентификатор клиента и секретные ключи клиента (полученные при регистрации приложения в 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>

Как настроить процессы с помощью правил

Для каждой конечной точки заданы правила. Ниже приведены примеры правил. Также ознакомьтесь с кратким обзором шагов, необходимых для добавления правил 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}

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

Это путь /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, как показано ниже. Обратите внимание, что токен доступа также называется токеном Bearer.

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

Также ознакомьтесь с информацией о том, как отправлять токен доступа.