Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Typ uwierzytelnienia właściciela zasobu (lub „hasło”) jest najczęściej używane w przypadkach, gdy aplikacja jest wysoce zaufana. W tej konfiguracji użytkownik podaje swoje 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 sprawdza dane logowania i jeśli są one prawidłowe, Edge generuje token dostępu i zwraca go do aplikacji.
O tym temacie
Ten temat zawiera ogólny opis i omówienie procesu przyznawania hasła właściciela zasobu OAuth 2.0 oraz sposób wdrażania tego procesu w Apigee Edge.
Przykłady, które mogą Ci się przydać
- Żądanie dostępu do tokena dostępu: typ uwierzytelnienia hasła: pokazuje, jak utworzyć żądanie tokena, skonfigurować zasadę OAuthV2 na potrzeby typu uwierzytelnienia hasła i jak skonfigurować punkt końcowy dla zasady w Edge.
- oauth-validate-key-secret: przykładowy serwer proxy na GitHubie, który możesz wdrożyć w Edge i wypróbować. To kompleksowy przykład przedstawiający typ przyznania hasła. Jest to sprawdzona metoda polegająca na uwierzytelnieniu danych logowania (klucza/tajnego) do aplikacji klienckiej przed wysłaniem danych logowania użytkownika do dostawcy tożsamości.
Wideo
Film: Obejrzyj ten film o implementowaniu typu przyznania hasła.
Przypadki użycia
Ten typ przyznania jest przeznaczony dla aplikacji o wysokim stopniu zaufania lub uprawnień, ponieważ użytkownik musi podać swoje dane logowania do serwera zasobów. Zwykle aplikacja zawiera ekran logowania, na którym użytkownik wpisuje swoje dane logowania.
Schemat blokowy
Poniższy schemat procesu ilustruje przepływ typu przyznania hasła właściciela zasobu z Apigee Edge działającym jako serwer 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 procesie dotyczącym typu przyznania hasła
Oto podsumowanie kroków wymaganych do zaimplementowania typu uwierzytelnienia hasła, w którym serwer autoryzacji Apigee Edge pełni funkcję serwera autoryzacji.
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. Użytkownik inicjuje proces i wpisuje dane logowania
Gdy aplikacja potrzebuje dostępu do chronionych zasobów użytkownika (np. klika przycisk w aplikacji), użytkownik jest przekierowywany do formularza logowania.
2. Aplikacja żąda tokena dostępu z 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 parametry wymagane dla tego typu uwierzytelnienia:
$ 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
Polecenie to można też wykonać w sposób opisany poniżej za pomocą opcji -u zawijania tekstu w celu utworzenia nagłówka uwierzytelniania podstawowego zakodowanego w standardzie 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
Wszystkie te polecenia powinny znajdować się w jednym wierszu.
Dane logowania użytkownika są zawarte w parametrach formularza, a dane logowania klienta są zakodowane w nagłówku podstawowego uwierzytelniania HTTP. Szczegółowy opis tego wywołania interfejsu API, w tym wymagany nagłówek uwierzytelniania podstawowego, znajdziesz w sekcji dotyczącej przyznawania haseł w artykule „Wysyłanie prośby o tokeny dostępu i kody autoryzacji”.
3. Edge weryfikuje aplikację kliencką
Zanim wyślesz nazwę użytkownika i hasło użytkownika do dostawcy tożsamości, Edge musi wiedzieć, że aplikacja kliencka wysyłająca żądanie jest prawidłową, zaufaną aplikacją. Jednym ze sposobów na to jest użycie uwierzytelniania klucza interfejsu API w wywołaniu interfejsu API. W niektórych przypadkach warto zweryfikować zarówno klucz klienta, jak i obiekt tajny. W repozytorium api-platform-samples na GitHubie znajdziesz przykładowy serwer proxy, który ilustruje tę uniwersalną technikę.
4. Edge przetwarza dane logowania.
Po zweryfikowaniu aplikacji klienckiej możesz użyć wywołania usługi lub zasady JavaScriptu, aby wywołać usługę tożsamości i wysłać dane logowania użytkownika. Może to być na przykład usługa LDAP lub dowolna usługa, której chcesz używać do weryfikowania danych logowania. Szczegółowe informacje o tych zasadach znajdziesz w artykułach o wyodrębnianiu zmiennych i zasadach JavaScriptu.
Jeśli usługa tożsamości sprawdzi dane logowania i zwróci odpowiedź 200, Edge będzie kontynuować przetwarzanie żądania. W przeciwnym razie Edge zatrzyma przetwarzanie i zwróci błąd aplikacji klienckiej.
5. Zasada OAuthV2 jest wykonywana
Jeśli dane logowania są prawidłowe, następnym krokiem przetwarzania jest wykonanie zasady OAuthV2 skonfigurowanej pod kątem typu przyznania hasła. 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 tych zasadach znajdziesz w artykule na temat zasad 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, dla klienta zostanie wygenerowana odpowiedź z tokenem dostępu. Odpowiedź jest w formacie JSON. Oto przykład. Zwróć uwagę, że token dostępu (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, przy zastosowaniu prawidłowego kodu 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. 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