Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację
Apigee X. info
W przypadku typu przyznawanych uprawnień klienta aplikacja wysyła własne dane logowania (identyfikator klienta i tajny klucz klienta) do punktu końcowego w Apigee Edge, który jest skonfigurowany do generowania tokena dostępu. Jeśli dane logowania są prawidłowe, Edge zwraca token dostępu do aplikacji klienckiej.
O tym temacie
W tym artykule znajdziesz ogólny opis typu przyznawanych uprawnień klienta OAuth 2.0 oraz informacje o tym, jak wdrożyć ten proces w Apigee Edge.
Przypadki użycia
Ten typ przyznawanych uprawnień jest najczęściej używany, gdy aplikacja jest też właścicielem zasobu. Na przykład, aplikacja może potrzebować dostępu do usługi przechowywania danych w chmurze, aby przechowywać i pobierać dane, których używa do wykonywania swoich zadań, a nie dane należące do użytkownika. Ten proces przyznawania uprawnień odbywa się wyłącznie między aplikacją kliencką a serwerem autoryzacji. Użytkownik nie uczestniczy w tym procesie.
Role
Role określają „aktorów” uczestniczących w procesie OAuth. Aby pokazać, gdzie w tym procesie znajduje się Apigee Edge, omówimy krótko role związane z danymi logowania klienta. Pełne omówienie ról OAuth 2.0 znajdziesz w specyfikacji IETF OAuth 2.0.
- Aplikacja kliencka – aplikacja, która potrzebuje dostępu do chronionych zasobów użytkownika. Zazwyczaj w tym procesie aplikacja działa na serwerze, a nie lokalnie na laptopie lub urządzeniu użytkownika.
- Apigee Edge – w tym procesie Apigee Edge jest serwerem autoryzacji OAuth serwerem. Jego zadaniem jest generowanie i weryfikowanie tokenów dostępu oraz przekazywanie autoryzowanych żądań dotyczących chronionych zasobów do serwera zasobów.
- Serwer zasobów – usługa backendu, która przechowuje chronione dane do których aplikacja kliencka potrzebuje uprawnień dostępu. Jeśli chronisz proxy interfejsów API hostowane w Apigee Edge, Apigee Edge jest też serwerem zasobów.
Przykładowy kod
Kompletną, działającą implementację typu przyznawanych uprawnień klienta znajdziesz na GitHubie. Linki do innych przykładów znajdziesz w sekcji Dodatkowe materiały poniżej.
Diagram przepływu
Na diagramie poniżej przedstawiono proces danych logowania klienta, w którym Apigee Edge pełni rolę serwera autoryzacji. Ogólnie rzecz biorąc, w tym procesie Edge jest też serwerem zasobów – to znaczy, proxy interfejsów API są chronionymi zasobami.
Kroki w procesie danych logowania klienta
Oto podsumowanie kroków wymaganych do wdrożenia typu przyznawanych uprawnień klienta w którym Apigee Edge pełni rolę serwera autoryzacji. Pamiętaj, że w tym procesie aplikacja kliencka po prostu przedstawia swój identyfikator klienta i tajny klucz klienta, a jeśli są one prawidłowe, Apigee Edge zwraca token dostępu.
Wymaganie wstępne: aplikacja kliencka musi być zarejestrowana w Apigee Edge, aby uzyskać identyfikator klienta i tajny klucz klienta. Szczegółowe informacje znajdziesz w artykule Rejestrowanie aplikacji klienckich.
1. Klient prosi o token dostępu
Aby otrzymać token dostępu, klient wysyła wywołanie interfejsu API POST do Edge z wartościami identyfikatora klienta i tajnego klucza klienta uzyskanymi z zarejestrowanej aplikacji dewelopera. Dodatkowo parametr grant_type=client_credentials musi być przekazywany jako parametr zapytania. (Możesz jednak skonfigurować zasadę OAuthV2 tak, aby akceptowała ten parametr w nagłówku żądania lub treści żądania – szczegółowe informacje znajdziesz w artykule Zasada OAuthV2).
Na przykład:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials&client_id=ns4fQc14Zg4hKFCNaSzArVuwszX95X&client_secret=ZIjFyTsNgQNyxI'
Uwaga: chociaż możesz przekazywać wartości identyfikator klienta i klucz klienta jako parametry zapytania, jak pokazano powyżej, zalecamy przekazywanie ich jako ciąg znaków zakodowany w formacie base64 w nagłówku Authorization. Aby to zrobić, musisz użyć narzędzia lub narzędzia do kodowania base64, aby zakodować 2 wartości razem z dwukropkiem. Na przykład: aBase64EncodeFunction(clientidvalue:clientsecret). W związku z tym powyższy przykład zostanie zakodowany w ten sposób:
result = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI) // Zwróć uwagę na dwukropek oddzielający 2 wartości.
Wynikiem kodowania base64 powyższego ciągu znaków jest: bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==
Następnie wyślij żądanie tokena w ten sposób:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg=='
2. Edge weryfikuje dane logowania
Pamiętaj, że wywołanie interfejsu API jest wysyłane do punktu końcowego /accesstoken. Do tego punktu końcowego jest dołączona zasada , która weryfikuje dane logowania aplikacji. Oznacza to, że zasada porównuje przesłane klucze z kluczami utworzonymi przez Apigee Edge podczas rejestracji aplikacji. Jeśli chcesz dowiedzieć się więcej o punktach końcowych OAuth w Edge, przeczytaj artykuł Konfigurowanie punktów końcowych i zasad OAuth.
3. Edge zwraca odpowiedź
Jeśli dane logowania są prawidłowe, Edge zwraca token dostępu do klienta. W przeciwnym razie zwracany jest błąd.
4. Klient wywołuje chroniony interfejs API
Teraz, gdy klient ma prawidłowy token dostępu, może wywoływać chroniony interfejs API. W tym scenariuszu żądania są wysyłane do Apigee Edge (proxy), a Edge odpowiada za weryfikację tokena dostępu przed przekazaniem wywołania interfejsu API do docelowego serwera zasobów. Przykład znajdziesz w sekcji Wywoływanie chronionego interfejsu API poniżej.
Konfigurowanie przepływów i zasad
Jako serwer autoryzacji Edge przetwarza żądania tokenów dostępu. Jako deweloper interfejsu API, musisz utworzyć proxy z niestandardowym przepływem, aby obsługiwać żądania tokenów, oraz dodać i skonfigurować zasadę OAuthV2. W tej sekcji dowiesz się, jak skonfigurować ten punkt końcowy.
Konfiguracja przepływu niestandardowego
Najłatwiej pokazać, jak skonfigurować przepływ proxy interfejsu API, jest pokazanie definicji przepływu XML. Oto przykład przepływu proxy interfejsu API zaprojektowanego do przetwarzania żądania tokena dostępu. Na przykład, gdy przychodzi żądanie, a sufiks ścieżki pasuje do /accesstoken, uruchamia się zasada GetAccessToken. Krótkie omówienie kroków wymaganych do utworzenia takiego przepływu niestandardowego znajdziesz w artykule Konfigurowanie punktów końcowych i zasad OAuth.
<Flows>
<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>GetAccessToken</Name></Step>
</Request>
</Flow>
</Flows>Konfigurowanie przepływu za pomocą zasady
Musisz dołączyć zasadę do punktu końcowego w ten sposób. Krótkie omówienie kroków wymaganych do dodania zasady OAuthV2 do punktu końcowego proxy znajdziesz w artykule Konfigurowanie punktów końcowych i zasad OAuth.
Uzyskiwanie tokena dostępu
Ta zasada jest dołączona do ścieżki /accesstoken. Używa zasady OAuthV2
z określoną operacją GenerateAccessToken.
<OAuthV2 name="GetAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>3600000</ExpiresIn>
<SupportedGrantTypes>
<GrantType>client_credentials</GrantType>
</SupportedGrantTypes>
<GenerateResponse/>
</OAuthV2>Wywołanie interfejsu API w celu uzyskania tokena dostępu to żądanie POST, które zawiera nagłówek Authorization z zakodowanym w formacie base64 identyfikatorem klienta + tajnym kluczem klienta oraz parametrem zapytania grant_type=client_credentials. Może też zawierać opcjonalne parametry scope i state. Na przykład:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVgT1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'
Dołączanie zasady weryfikacji tokena dostępu
Aby chronić interfejs API za pomocą zabezpieczeń OAuth 2.0, musisz dodać zasadę OAuthV2 z operacją VerifyAccessToken. Ta zasada sprawdza, czy przychodzące żądania mają prawidłowy token dostępu. Jeśli token jest prawidłowy, Edge przetwarza żądanie. Jeśli nie jest prawidłowy, Edge zwraca błąd. Podstawowe kroki znajdziesz w artykule Weryfikowanie tokenów dostępu.
<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
<DisplayName>VerifyAccessToken</DisplayName>
<ExternalAuthorization>false</ExternalAuthorization>
<Operation>VerifyAccessToken</Operation>
<SupportedGrantTypes/>
<GenerateResponse enabled="true"/>
<Tokens/>
</OAuthV2>Wywoływanie chronionego interfejsu API
Aby wywołać interfejs API chroniony za pomocą zabezpieczeń OAuth 2.0, musisz przedstawić prawidłowy token dostępu. Prawidłowy wzorzec polega na dołączeniu tokena w nagłówku Authorization w ten sposób: pamiętaj że token dostępu jest też nazywany „tokenem okaziciela”.
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Zobacz też Wysyłanie tokena dostępu.
Dodatkowe materiały
- Apigee oferuje szkolenia online dla deweloperów interfejsów API, w tym kurs dotyczący zabezpieczeń interfejsów API, który obejmuje OAuth.
- Zasada OAuthV2 – zawiera wiele przykładów pokazujących, jak wysyłać żądania do serwera autoryzacji i jak skonfigurować zasadę OAuthV2.