Przeglądasz dokumentację Apigee Edge.
Przejdź do
Dokumentacja Apigee X. informacje.
W przypadku typu przyznania danych logowania klienta aplikacja wysyła własne dane logowania (identyfikator klienta Client Secret) do punktu końcowego 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 temacie znajdziesz ogólny opis typu przyznawania danych logowania klienta OAuth 2.0 oraz Wyjaśnia, jak wdrożyć ten proces w Apigee Edge.
Przypadki użycia
Zwykle ten typ uwierzytelnienia jest używany, gdy aplikacja jest też właścicielem zasobu. Przykład: aplikacja może potrzebować dostępu do usługi backendu działającej w chmurze, aby przechowywać i pobierać dane, danych, których używa do wykonania swojej pracy, a nie danych należących do użytkownika. Ten typ uwierzytelnienia między aplikacją kliencką a serwerem autoryzacji. Użytkownik końcowy nie i brać udział w procesie udzielania grantów.
Role
Role określają „aktorów” które uczestniczą w procesie OAuth. Omówmy pokrótce: roli danych logowania klienta, aby pokazać, gdzie pasuje Apigee Edge. Pełną listę omówienie ról OAuth 2.0 znajdziesz w specyfikacji IETF OAuth 2.0.
- Aplikacja kliencka – aplikacja, która wymaga dostępu do chronionych przez użytkownika danych. i zasobami Google Cloud. Zwykle w tym procesie aplikacja działa na serwerze, a nie lokalnie laptopa lub urządzenia.
- Apigee Edge – w tym procesie Apigee Edge służy do autoryzacji OAuth. serwera. Jego rola to generowanie tokenów dostępu, weryfikowanie tokenów dostępu i przekazywanie autoryzowanych żądaniami zabezpieczonych zasobów na serwerze 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 interfejsu API hostowane w Apigee Edge, wówczas Apigee Edge jest także serwerem zasobów.
Przykładowy kod
Kompletny, działający przykładową implementację typu przyznawania danych logowania klienta na GitHubie. Linki do dodatkowych przykładów znajdziesz poniżej w sekcji Dodatkowe materiały.
Schemat przepływu
Poniższy diagram przepływu przedstawia przepływ danych logowania klienta z Apigee Edge obsługującym oraz serwer autoryzacji. Ogólnie Edge jest również serwerem zasobów w tym procesie, czyli Serwery proxy interfejsów API to zasoby chronione.
Kroki w przepływie danych logowania klienta
Oto podsumowanie czynności wymaganych do wdrożenia typu przyznania kodu danych logowania klienta gdzie Apigee Edge służy jako serwer autoryzacji. Pamiętaj, że w przypadku tej procedury aplikacja kliencka po prostu wyświetla swój identyfikator klienta i tajny klucz klienta, a jeśli są prawidłowe, Apigee Edge zwraca token dostępu.
Warunek wstępny: aby można było uzyskać dostęp, aplikacja kliencka musi być zarejestrowana w Apigee Edge identyfikatora klienta i klucza tajnego klienta. Patrz sekcja Rejestrowanie aplikacji klienckich dla: .
1. Klient prosi o token dostępu
Aby otrzymać token dostępu, klient wykonuje wywołanie interfejsu API do Edge z wartościami identyfikatora klienta i tajny klucz klienta uzyskany z zarejestrowanych aplikacji dewelopera. Dodatkowo parametr Grant_type=client_credentials musi być przekazywany jako parametr zapytania. (możesz jednak skonfigurować zasady OAuthV2 umożliwiające akceptowanie tego parametru w nagłówku lub treści żądania (więcej informacji znajdziesz w artykule Zasady 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ż w zapytaniu możesz przekazać wartości client_id i customer_secret (identyfikator klienta) jak pokazano powyżej, warto przekazać je jako ciąg zakodowany w formacie base64 nagłówek autoryzacji. Aby to zrobić, musisz użyć narzędzia do kodowania base64 lub innego narzędzia do kodowania obie te wartości, oddzielając je dwukropkiem. W ten sposób: aBase64EncodeFunction(clientidvalue:clientsecret). Powyższy przykład miałby więc kodowanie to:
wynik = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI) // Zwróć uwagę na dwukropek, który oddziela obie wartości.
Wynik kodowania powyższego ciągu za pomocą base64 to: bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==
Następnie wyślij żądanie tokena w następujący 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. Ten punkt końcowy ma zasadę w celu weryfikacji danych logowania do aplikacji. Oznacza to, że zasada porównuje przesłane z kluczami utworzonymi przez Apigee Edge podczas rejestrowania aplikacji. Jeśli chcesz więcej informacji o punktach końcowych OAuth w Edge znajdziesz w artykule o konfigurowaniu protokołu OAuth. punktów końcowych i zasad.
3. Edge zwraca odpowiedź
Jeśli dane logowania są prawidłowe, Edge zwraca token dostępu klientowi. W przeciwnym razie pojawi się błąd: .
4. Klient wywołuje metodę Protected API
Teraz dzięki prawidłowemu tokenowi dostępu klient może wywoływać chroniony interfejs API. W tym Scenariusze są wysyłane do Apigee Edge (serwera proxy), a Edge odpowiada za ich weryfikację token dostępu przed przekazaniem wywołania interfejsu API do docelowego serwera zasobów. Na przykład: zapoznaj się z sekcją 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 API musisz utworzyć serwer proxy z niestandardowym przepływem do obsługi żądań tokenów oraz dodać i skonfigurować zasadom OAuthV2. Z tej sekcji dowiesz się, jak skonfigurować ten punkt końcowy.
Niestandardowa konfiguracja przepływu
Najłatwiejszym sposobem pokazania, jak skonfigurowany jest przepływ serwera proxy interfejsu API, jest pokazanie przepływu XML. definicji. Oto przykładowy przepływ serwera proxy interfejsu API zaprojektowany w celu przetworzenia żądania tokena dostępu. Dla: Jeśli na przykład przychodzi żądanie i sufiks ścieżki pasuje do /accesstoken, obiekt GetAccessToken . Zobacz Konfigurowanie protokołu OAuth punktów końcowych i zasad, w których znajdziesz krótkie omówienie kroków niezbędnych do utworzenia niestandardowego przepływu. w ten sposób.
<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. Zobacz Konfigurowanie protokołu OAuth punktów końcowych i zasad, w których znajdziesz krótkie omówienie czynności, które trzeba wykonać, aby dodać zasadę OAuthV2. do punktu końcowego serwera proxy.
Uzyskiwanie tokena dostępu
Ta zasada jest połączona ze ścieżką /accesstoken. Wykorzystuje protokół 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 umożliwiające uzyskanie tokena dostępu jest metodą POST i zawiera nagłówek autoryzacji z identyfikator klienta + tajny klucz klienta zakodowany w base64 i parametr zapytania grant_type=client_credentials. Może też zawierać opcjonalne parametry zakresu i stanu. Dla: 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ć swój interfejs API za pomocą zabezpieczeń OAuth 2.0, musisz dodać zasadę OAuthV2 z atrybutem VerifyAccessToken (operacja VerifyAccessToken). Ta zasada sprawdza, czy żądania przychodzące mają prawidłowy token dostępu. Jeśli token jest prawidłowy, Edge przetwarza żądanie. Jeśli jest nieprawidłowy, Edge zwraca błąd. Dla: opisane w artykule Weryfikacja tokeny 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 dostęp token. Prawidłowym wzorcem jest umieszczenie tokena w nagłówku autoryzacji 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
Zobacz też Wysyłanie dostępu .
Dodatkowe materiały
- Apigee oferuje szkolenia online dla deweloperów interfejsów API, w tym kurs na temat Interfejs API zabezpieczeń, w tym protokołu OAuth.
- Zasady OAuthV2 – zawiera wiele przykładów pokazujących, jak wysyłać żądania do serwera autoryzacji i jak je konfigurować zasady OAuthV2.