Понимание конечных точек OAuth

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

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

Что такое конечная точка OAuth2?

Конечная точка OAuth2 — это URL-адрес, который клиенты используют для запроса токенов OAuth (или кодов авторизации). Вот пример запроса на получение токена доступа:

$ curl -i -H 'ContentType: x-www-form-urlencoded' \
-X POST 'https://docs-test.apigee.net/oauth/client_credential/accesstoken' \
-d 'grant_type=client_credentials' \
-H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'

В вашей среде Apigee Edge для обработки запросов такого типа требуется политика. Как можно понять из запроса, политика должна поддерживать тип предоставления доступа «учетные данные клиента» и выполняться по пути /oauth/client_credentials/accesstoken .

В данном случае правильной политикой является политика OAuthV2, настроенная для выполнения в потоке, подобном тому, что показан в следующем примере (где имя политики — GenerateAccessTokenClient):

        <Flow name="AccessTokenClientCredential">
            <Description/>
            <Request>
                <Step>
                    <FaultRules/>
                    <Name>GenerateAccessTokenClient</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath &quot;/accesstoken&quot;) and (request.verb = &quot;POST&quot;)</Condition>
        </Flow>

Если клиент предоставляет корректные учетные данные, политика генерирует и возвращает токен; в противном случае она возвращает ошибку.

Определение местоположения конечных точек по умолчанию

Apigee по умолчанию добавляет пример прокси-сервера OAuth2 в каждую новую создаваемую организацию. Если вы посмотрите, то найдете прокси-сервер с именем oauth в вашей организации.

Чтобы найти этот прокси:

  1. Перейдите на страницу «API-прокси», как описано ниже.

    Край

    Чтобы получить доступ к странице «API-прокси» через пользовательский интерфейс Edge:

    1. Войдите на сайт apigee.com/edge .
    2. В левой панели навигации выберите «Разработка» > «API-прокси» .
    3. Click +Proxy

    Классический Edge (частное облако)

    Чтобы получить доступ к странице «API-прокси» с помощью классического интерфейса Edge:

    1. Войдите в систему по http:// ms-ip :9000 , где ms-ip — это IP-адрес или DNS-имя узла сервера управления.
    2. В верхней панели навигации выберите API > API-прокси .
  2. В списке прокси-серверов выберите тот, который называется oauth .
  3. На странице обзора прокси-сервера выберите вкладку «Разработка» , чтобы открыть редактор прокси-серверов, и изучите политики и потоки в прокси-сервере.

Рекомендация: Создайте собственный прокси-сервер для аутентификации OAuth2.

Стандартный прокси-сервер OAuth имеет ограничения: он поддерживает только тип предоставления учетных данных клиента. Этот прокси-сервер предназначен только для примера. Для использования в производственной среде вам потребуется создать прокси-сервер, который настроит конечные точки OAuth2 в соответствии с вашими требованиями.

Важное замечание: прокси-сервер, определяющий конечные точки OAuth2, обычно является прокси-сервером без целевого объекта. Прокси-сервер действует как служба, которая выполняется в ProxyEndpoint и возвращает данные непосредственно клиенту.

Связанные темы

Запрос токенов доступа и кодов авторизации.