Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Z typem uwierzytelnienia klienta aplikacja wysyła własne dane logowania (identyfikator klienta i tajny klucz klienta) do punktu końcowego w Apigee Edge skonfigurowanego pod kątem generowania tokena dostępu. Jeśli dane logowania są prawidłowe, Edge zwraca token dostępu do aplikacji klienta.
O tym temacie
Ten temat zawiera ogólny opis typu uwierzytelnienia klienta OAuth 2.0 oraz sposób wdrażania tego procesu w Apigee Edge.
Przypadki użycia
Najczęściej ten typ uwierzytelniania jest używany, gdy aplikacja jest też właścicielem zasobu. Na przykład aplikacja może potrzebować dostępu do backendu w chmurze, aby przechowywać i pobierać dane używane do wykonywania swoich zadań, a nie dane należące do użytkownika końcowego. Ten przepływ typu uwierzytelnienia odbywa się ściśle między aplikacją kliencką a serwerem autoryzacji. Użytkownik końcowy nie bierze udziału w tym procesie uwierzytelniania.
Role
Role określają podmioty, które uczestniczą w procesie OAuth. Przyjrzyjmy się krótko rolam danych logowania klienta i zilustrujmy, jak wpasowuje się w nią Apigee Edge. Pełne omówienie ról OAuth 2.0 znajdziesz w specyfikacji protokołu OAuth 2.0 IETF.
- Aplikacja kliencka – aplikacja, która wymaga dostępu do chronionych zasobów użytkownika. W tym przypadku aplikacja działa zwykle na serwerze, a nie lokalnie na laptopie lub urządzeniu użytkownika.
- Apigee Edge – w tym procesie Apigee Edge jest serwerem autoryzacji OAuth. Jego rola to generowanie tokenów dostępu, weryfikowanie tokenów dostępu i przekazywanie autoryzowanych żądań dotyczących zabezpieczonych zasobów na serwer 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 serwery proxy API hostowane w Apigee Edge, to Apigee Edge jest również serwerem zasobów.
Przykładowy kod
Pełną, działającą przykładową implementację typu uwierzytelnienia danych logowania klienta znajdziesz na GitHubie. Poniżej znajdziesz linki do dodatkowych przykładów w sekcji Dodatkowe materiały.
Schemat blokowy
Poniższy diagram przedstawia przepływ danych logowania klienta z Apigee Edge pełniącym funkcję serwera autoryzacji. Ogólnie rzecz biorąc, Edge jest też serwerem zasobów w tym procesie, co oznacza, że zabezpieczonymi zasobami interfejsu API są serwery proxy API.
Etapy przepływu danych logowania klienta
Oto podsumowanie kroków wymaganych do zaimplementowania typu uwierzytelnienia kodu danych logowania klienta, w którym jako serwer autoryzacji działa Apigee Edge. Pamiętaj, że w tym procesie aplikacja kliencka prezentuje po prostu swój identyfikator klienta i tajny klucz klienta, a jeśli są prawidłowe, Apigee Edge zwraca token dostępu.
Warunek wstępny: aby uzyskać identyfikator klienta i klucze tajnego klucza klienta, aplikacja klienta musi być zarejestrowana w Apigee Edge. Więcej informacji znajdziesz w sekcji Rejestrowanie aplikacji klienckich.
1. Klient żąda tokena dostępu
Aby otrzymać token dostępu, klient POST wysyła wywołanie interfejsu API do przeglądarki Edge z wartościami identyfikatora klienta i tajnego klucza klienta uzyskanych z zarejestrowanej aplikacji dewelopera. Dodatkowo należy przekazać parametr grant_type=client_credentials jako parametr zapytania. Możesz jednak skonfigurować zasadę OAuthV2 tak, aby akceptowała ten parametr w nagłówku lub treści żądania. Szczegóły znajdziesz w zasadach 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 client_id i client_secret jako parametrów zapytania, jak pokazano powyżej, warto przekazywać je jako ciąg zakodowany w standardzie base64 w nagłówku Authorization. Aby to zrobić, musisz zakodować te 2 wartości za pomocą narzędzia do kodowania base64 lub oddzielać je dwukropkiem. Przykład: aBase64EncodeFunction(clientidvalue:clientsecret). Powyższy przykład zostałby zakodowany w ten sposób:
wynik = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI) // Zwróć uwagę na dwukropek oddzielający te wartości.
Wynik zakodowania tego ciągu w base64 to: 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 uwierzytelniające
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 do 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ł o konfigurowaniu punktów końcowych i zasad OAuth.
3. Edge zwraca odpowiedź
Jeśli dane logowania są prawidłowe, Edge zwraca token dostępu klienta. W przeciwnym razie zwracany jest błąd.
4. Klient wywołuje chroniony interfejs API
Teraz, przy zastosowaniu prawidłowego tokena dostępu, klient może wywoływać chroniony interfejs API. W tym scenariuszu żądania są wysyłane do Apigee Edge (serwera proxy) i 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 programista interfejsu API musisz utworzyć serwer proxy z niestandardowym procesem, aby obsługiwać żądania tokenów oraz dodać i skonfigurować zasadę OAuthV2. Z tej sekcji dowiesz się, jak skonfigurować ten punkt końcowy.
Niestandardowa konfiguracja przepływu
Najprostszym sposobem pokazania konfiguracji przepływu serwera proxy interfejsu API jest pokazanie definicji przepływu XML. Oto przykładowy przepływ serwera proxy interfejsu API, którego celem jest przetworzenie żądania tokena dostępu. Jeśli na przykład przychodzi żądanie, a sufiks ścieżki pasuje do ciągu /accesstoken, zostanie aktywowana zasada GetAccessToken. W artykule Konfigurowanie punktów końcowych i zasad OAuth znajdziesz krótkie omówienie czynności, które musisz wykonać, by utworzyć taki przepływ niestandardowy.
<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 następujący sposób. W artykule Konfigurowanie punktów końcowych i zasad OAuth znajdziesz krótkie omówienie czynności, które musisz wykonać, aby dodać zasadę OAuthV2 do punktu końcowego serwera proxy.
Uzyskaj token 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 mające na celu uzyskanie tokena dostępu to żądanie POST i zawiera nagłówek Authorization z parametrem client_id zakodowanym w base64, client_id, client+secret oraz parametrem zapytania. Może też zawierać opcjonalne parametry zakresu i stanu. 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łączam zasadę dotyczącą tokenów weryfikacji dostępu
Aby chronić interfejs API za pomocą protokołu OAuth 2.0, musisz dodać zasadę OAuthV2 z operacjamiVerifyAccessToken. Ta zasada sprawdza, czy żądania przychodzące mają prawidłowy token dostępu. Jeśli token jest prawidłowy, Edge przetwarza żądanie. Jeśli wartość jest nieprawidłowa, Edge zwraca błąd. Podstawowe instrukcje znajdziesz w sekcji 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 przez uwierzytelnianie OAuth 2.0, musisz przedstawić prawidłowy token dostępu. Prawidłowy wzór należy umieścić w nagłówku Authorization w następujący sposób: Uwaga: token dostępu jest też nazywany „tokenem okaziciela”.
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Więcej informacji znajdziesz w sekcji Wysyłanie tokena dostępu.
Dodatkowe materiały
- Apigee oferuje szkolenia online dla programistów interfejsów API, w tym kurs na temat bezpieczeństwa interfejsów API, w tym protokołu OAuth.
- Zasada OAuthV2 – zawiera wiele przykładów pokazujących, jak wysyłać żądania do serwera autoryzacji i jak skonfigurować zasady OAuthV2.