Informacje o punktach końcowych OAuth

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Aby Apigee Edge mogło pełnić funkcję serwera autoryzacji OAuth2, musi udostępniać punkty końcowe , w których klienci mogą żądać tokenów i kodów autoryzacji. W tym artykule znajdziesz krótkie wprowadzenie do tych punktów końcowych oraz dowiesz się, jak je skonfigurować w Edge.

Co to jest punkt końcowy OAuth2?

Punkt końcowy OAuth2 to adres URL, który klienci wywołują, aby poprosić o tokeny OAuth (lub kody autoryzacji). Oto przykładowe żądanie tokena dostępu:

$ 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'

W środowisku Apigee Edge do obsługi tego rodzaju żądań wymagana jest zasada. Jak można wywnioskować z żądania, zasada musi obsługiwać typ przyznawanych uprawnień „dane uwierzytelniające klienta” i musi być wykonywana w ścieżce /oauth/client_credentials/accesstoken.

W tym przypadku prawidłową zasadą jest zasada OAuthV2 skonfigurowana do wykonywania w przepływie takim jak ten przedstawiony w poniższym przykładzie (gdzie nazwa zasady to 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>

Jeśli klient poda prawidłowe dane uwierzytelniające, zasada wygeneruje i zwróci token. W przeciwnym razie, zwróci błąd.

Lokalizowanie domyślnych punktów końcowych

Apigee domyślnie dodaje przykładowy serwer proxy punktu końcowego OAuth2 do każdej nowej organizacji, którą tworzy. Jeśli poszukasz, w swojej organizacji znajdziesz serwer proxy o nazwie oauth.

Aby znaleźć ten serwer proxy:

1. Otwórz stronę Serwery proxy interfejsów API, tak jak opisano poniżej.

   Edge

   Aby otworzyć stronę Serwery proxy interfejsów API za pomocą interfejsu Edge:

   1. Zaloguj się na apigee.com/edge.
   2. Na lewym pasku nawigacji wybierz Tworzenie > Serwery proxy interfejsów API.
   3. Kliknij +Serwer proxy.

   Classic Edge (Private Cloud)

   Aby otworzyć stronę Serwery proxy interfejsów API za pomocą interfejsu Classic Edge:

   1. Zaloguj się na http://ms-ip:9000, gdzie ms-ip to adres IP lub nazwa DNS węzła serwera zarządzania.
   2. Na górnym pasku nawigacji wybierz Interfejsy API > Serwery proxy interfejsów API.
2. Na liście serwerów proxy wybierz serwer o nazwie oauth.
3. Na stronie przeglądu serwera proxy kliknij kartę Tworzenie, aby otworzyć edytor serwera proxy, a następnie sprawdź zasady i przepływy w serwerze proxy.

Sprawdzona metoda: utwórz własny serwer proxy punktu końcowego OAuth2

Domyślny oauth serwer proxy ma ograniczenia: obsługuje tylko typ przyznawanych uprawnień danych uwierzytelniających klienta. Ten serwer proxy ma być tylko przykładem. W przypadku środowiska produkcyjnego warto utworzyć serwer proxy który konfiguruje punkty końcowe OAuth2 spełniające Twoje wymagania.

Ważna uwaga: serwer proxy, który definiuje punkty końcowe OAuth2, jest zwykle serwerem proxy bez miejsca docelowego. Serwer proxy działa jako usługa, która jest wykonywana w ProxyEndpoint i zwraca odpowiedź bezpośrednio z powrotem do klienta.

Powiązane artykuły

Żądanie tokenów dostępu i kodów autoryzacji