Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info
Использование токенов OAuth сторонних производителей
См. раздел «Использование сторонних токенов OAuth» .
Указание нескольких URL-адресов обратного вызова
При использовании типа предоставления кода авторизации необходимо указать URL-адрес обратного вызова при регистрации приложения разработчика. URL-адрес обратного вызова обычно указывает URL-адрес приложения, которому поручено получать код авторизации от имени клиентского приложения. Кроме того, эта строка URL-адреса используется для проверки. Клиент обязан отправить этот URL-адрес в Apigee Edge при запросе кодов авторизации и токенов доступа, а параметр redirect_uri должен совпадать с зарегистрированным. См. также Запрос токенов доступа и кодов авторизации .
Например:
http://myorg-test.apigee.net/weather/oauth/authorizationcode?client_id=123456&response_type=code&redirect_uri=http://example.com/callback&scope=scope1%20scope2&state=abc
Существует сценарий использования, при котором в одном прокси-приложении указывается несколько URL-адресов обратного вызова. Например, может потребоваться аутентификация для нескольких доменов. Например:
- http://myexample.com/callback
- http://myexample.uk/callback
- http://myexample.ja/callback
Edge не поддерживает указание нескольких URL-адресов обратного вызова или использование символов подстановки при регистрации приложения разработчика. Для решения этой задачи можно указать пустой URL-адрес обратного вызова при регистрации приложения разработчика, а затем добавить логику в политику JavaScript для проверки входящих URI перенаправления.
Изменение поведения по умолчанию при возврате результата операции GenerateAuthCode
По умолчанию операция GenerateAuthCode политики OAuthV2 возвращает перенаправление 302 на URL-адрес обратного вызова с параметром запроса ?code, содержащим код авторизации.
В некоторых случаях может потребоваться изменить это поведение. Например, может потребоваться вернуть ответ с кодом 200 в структурированном JSON-формате, содержащем код.
Один из способов реализовать этот сценарий — установить свойство GenerateResponse политики OAuthV2 в false . Используйте политику ExtractVariable , чтобы получить значение кода авторизации из переменной oauthv2authcode.{policy_name}.code . Затем вы можете использовать политику AssignMessage для возврата кода в JSON-данные со статусом 200.
Аудит согласия конечного пользователя приложения
Вам может потребоваться проверить, авторизовал ли приложение конечный пользователь. Для этого можно использовать API аудита Apigee Edge.
Пример исходящей аутентификации OAuth
Пример использования outbound-oauth можно найти в репозитории Apigee api-platform-samples на GitHub. Вы можете клонировать пример, развернуть его и запустить. В этом примере используется API переводчика Microsoft Azure для перевода твитов. Для этого он выполняет исходящий вызов для получения токена доступа OAuth, а затем кэширует токен, используя политики кэширования API Services, повторно используя кэшированный токен каждый раз при выполнении исходящего вызова. Также включено демонстрационное браузерное приложение, используемое для вызова прокси-сервера API.