Эта страница переведена с помощью 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-advanced в каталоге api-platform-samples/sample-proxy. Подробнее об образце см. в файле 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 получает запрос 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. Для этого он отправляет идентификатор клиента и секретные ключи клиента (полученные при регистрации приложения в 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}

Рекомендация: приложение для входа в систему обычно отправляет ответ перенаправления обратно в 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

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