Wyświetlasz dokumentację Apigee Edge.
Przejdź do
dokumentacji Apigee X. info
Typ przyznawanych uprawnień z hasłem właściciela zasobu (lub „hasłem”) jest najczęściej używany w przypadkach, gdy aplikacja jest bardzo zaufana. W tej konfiguracji użytkownik podaje dane logowania do serwera zasobów (nazwę użytkownika i hasło) aplikacji klienckiej, która wysyła je w żądaniu tokena dostępu do Apigee Edge. Serwer tożsamości weryfikuje dane logowania, a jeśli są one prawidłowe, Edge generuje token dostępu i zwraca go do aplikacji.
O tym temacie
W tym artykule znajdziesz ogólny opis i omówienie przepływu typu przyznawanych uprawnień z hasłem właściciela zasobu OAuth 2.0 oraz dowiesz się, jak zaimplementować ten przepływ w Apigee Edge.
Przykłady, które mogą Ci się przydać
- Żądanie tokena dostępu: typ przyznawanych uprawnień z hasłem: pokazuje, jak utworzyć żądanie tokena, skonfigurować zasadę OAuthV2 dla typu przyznawanych uprawnień z hasłem oraz jak skonfigurować punkt końcowy dla zasady w Edge.
- oauth-validate-key-secret: przykładowy serwer proxy w GitHubie, który możesz wdrożyć w Edge i wypróbować. Jest to kompleksowy przykład z typem przyznawanych uprawnień z hasłem. Pokazuje on sprawdzoną metodę, która polega na uwierzytelnieniu danych logowania aplikacji klienckiej (klucza i tajnego klucza) przed wysłaniem danych logowania użytkownika do dostawcy tożsamości.
Wideo
Wideo: zobacz ten film o implementowaniu typu przyznawanych uprawnień z hasłem.
Przypadki użycia
Ten typ przyznawanych uprawnień jest przeznaczony dla aplikacji o wysokim poziomie zaufania lub uprawnień, ponieważ użytkownik musi podać aplikacji dane logowania do serwera zasobów. Zazwyczaj aplikacja wyświetla ekran logowania, na którym użytkownik wpisuje swoje dane logowania.
Diagram przepływu
Na diagramie poniżej przedstawiono przepływ typu przyznawanych uprawnień z hasłem właściciela zasobu, w którym Apigee Edge pełni rolę serwera autoryzacji.
Wskazówka: aby wyświetlić większą wersję tego diagramu, kliknij go prawym przyciskiem myszy i otwórz w nowej karcie lub zapisz i otwórz w przeglądarce obrazów.
Kroki w przepływie typu przyznawanych uprawnień z hasłem
Oto podsumowanie kroków wymaganych do zaimplementowania typu przyznawanych uprawnień z hasłem, w którym Apigee Edge pełni rolę serwera autoryzacji.
Wymaganie wstępne: aplikacja kliencka musi być zarejestrowana w Apigee Edge, aby uzyskać identyfikator klienta i tajny klucz klienta. Więcej informacji znajdziesz w artykule Rejestrowanie aplikacji klienckich.
1. Użytkownik inicjuje przepływ i wpisuje dane logowania
Gdy aplikacja musi uzyskać dostęp do chronionych zasobów użytkownika (np. użytkownik kliknie przycisk w aplikacji), użytkownik zostanie przekierowany do formularza logowania.
2. Aplikacja prosi o token dostępu w Apigee Edge
Aplikacja wysyła żądanie tokena dostępu, w tym dane logowania użytkownika, do punktu końcowego GenerateAccessToken w Apigee Edge.
Oto przykładowe żądanie POST, które zawiera wymagane parametry dla tego typu przyznawanych uprawnień:
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
Alternatywnie to polecenie można wykonać w ten sposób, używając opcji -u w curl aby utworzyć nagłówek uwierzytelniania podstawowego zakodowany w formacie base64.
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
(Każde z tych poleceń powinno znajdować się w jednym wierszu).
Dane logowania użytkownika są zawarte w parametrach formularza, a dane logowania klienta są zakodowane w nagłówku uwierzytelniania podstawowego HTTP. Szczegółowy opis tego wywołania interfejsu API, w tym informacje o wymaganym nagłówku uwierzytelniania podstawowego, znajdziesz w sekcji dotyczącej przyznawania uprawnień z hasłem w artykule "Żądanie tokenów dostępu i kodów autoryzacji".
3. Edge weryfikuje aplikację kliencką
Zanim Edge wyśle nazwę użytkownika i hasło do dostawcy tożsamości, musi wiedzieć że aplikacja kliencka wysyłająca żądanie jest prawidłową, zaufaną aplikacją. Jednym ze sposobów na to jest użycie uwierzytelniania za pomocą klucza interfejsu API w wywołaniu interfejsu API. W niektórych przypadkach możesz chcieć zweryfikować zarówno klucz klienta, jak i tajny klucz. W repozytorium api-platform-samples w GitHubie znajduje się przykładowy serwer proxy, który ilustruje tę alternatywną technikę.
4. Edge przetwarza dane logowania
Po zweryfikowaniu aplikacji klienckiej możesz użyć zasady Service Callout lub JavaScript, aby wywołać usługę tożsamości, wysyłając dane logowania użytkownika. Może to być np. usługa LDAP lub dowolna usługa, której chcesz użyć do zweryfikowania danych logowania. Szczegółowe informacje o tych zasadach, patrz Zasada Extract Variables i Zasada JavaScript.
Jeśli usługa tożsamości zweryfikuje dane logowania i zwróci odpowiedź 200, Edge będzie kontynuować przetwarzanie żądania. W przeciwnym razie Edge zatrzyma przetwarzanie i zwróci błąd do aplikacji klienckiej.
5. Wykonuje się zasada OAuthV2
Jeśli dane logowania są prawidłowe, następnym krokiem przetwarzania jest wykonanie zasady OAuthV2 skonfigurowanej dla typu przyznawanych uprawnień z hasłem. Oto przykład. Elementy <UserName> i <PassWord> są wymagane. Możesz je pobrać ze zmiennych przepływu, które zostały zapisane za pomocą zasady ExtractVariables. Szczegółowe informacje o tej zasadzie, znajdziesz w artykule Zasada OAuthV2.
<OAuthV2 name="GetAccessToken"> <Operation>GenerateAccessToken</Operation> <ExpiresIn>360000000</ExpiresIn> <SupportedGrantTypes> <GrantType>password</GrantType> </SupportedGrantTypes> <GrantType>request.queryparam.grant_type</GrantType> <UserName>login</UserName> <PassWord>password</PassWord> <GenerateResponse/> </OAuthV2>
Jeśli ta zasada się powiedzie, do klienta zostanie wygenerowana odpowiedź zawierająca token dostępu. Odpowiedź jest w formacie JSON. Oto przykład. Zwróć uwagę, że access_token jest jednym z elementów:
{ "issued_at": "1420258685042", "scope": "READ", "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b", "refresh_token_issued_at": "1420258685042", "status": "approved", "refresh_token_status": "approved", "api_product_list": "[PremiumWeatherAPI]", "expires_in": "1799", "developer.email": "tesla@weathersample.com", "organization_id": "0", "token_type": "BearerToken", "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq", "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT", "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6", "organization_name": "docs", "refresh_token_expires_in": "0", "refresh_count": "0" }
6. Klient wywołuje chroniony interfejs API
Teraz, gdy klient ma prawidłowy kod dostępu, może wywoływać chroniony interfejs API. W tym scenariuszu żądania są wysyłane do Apigee Edge (serwera proxy), a Edge odpowiada za weryfikację tokena dostępu przed przekazaniem wywołania interfejsu API do docelowego serwera zasobów. Tokeny dostępu są przekazywane w nagłówku autoryzacji. Na przykład:
$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6 " http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282