Włącz pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika, identyfikatora aplikacji lub obu tych parametrów

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
info

Z tej sekcji dowiesz się, jak włączyć pobieranie i odwoływanie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika lub identyfikatora aplikacji albo obu tych identyfikatorów. Funkcja identyfikatora użytkownika wymaga specjalnej konfiguracji opisanej w tym temacie. Przez „użytkownika” rozumiemy użytkownika aplikacji, która wywołuje interfejs API.

Kiedy włączyć dostęp na podstawie identyfikatora użytkownika

Czasami warto przechowywać identyfikator użytkownika w tokenie dostępu. Włącz funkcję dostępu na podstawie identyfikatora użytkownika tylko wtedy, gdy masz odpowiedni przypadek użycia. Na przykład:

  • Funkcja w witrynie lub aplikacji, która umożliwia użytkownikom sprawdzenie, które aplikacje innych firm mają dostęp do danych, oraz umożliwia odebranie dostępu tym aplikacjom.
  • Funkcja, która umożliwia upoważnionemu użytkownikowi unieważnienie wszystkich tokenów dostępu powiązanych z konkretną aplikacją dewelopera.

Informacje o tokenach dostępu OAuth

Identyfikatory aplikacji są automatycznie dodawane do tokena dostępu OAuth. Dlatego po włączeniu dostępu na podstawie tokena dla organizacji, jak opisano poniżej, możesz cofnąć tokeny dostępu według identyfikatora aplikacji.

Aby pobrać i unieważnić tokeny dostępu OAuth 2.0 według identyfikatora użytkownika, musisz mieć w tokenach dostępu identyfikator użytkownika. Poniżej opisaliśmy, jak dodać identyfikator użytkownika do istniejącego tokena.

Domyślnie, gdy Edge generuje token dostępu OAuth 2.0, ma on format pokazany poniżej:

{
 "issued_at" : "1421847736581",
 "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
 "scope" : "READ",
 "status" : "approved",
 "api_product_list" : "[PremiumWeatherAPI]",
 "expires_in" : "3599", //--in seconds
 "developer.email" : "tesla@weathersample.com",
 "organization_id" : "0",
 "token_type" : "BearerToken",
 "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
 "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
 "organization_name" : "myorg",
 "refresh_token_expires_in" : "0", //--in seconds
 "refresh_count" : "0"
}

Pamiętaj:

  • Pole application_name zawiera identyfikator UUID aplikacji powiązanej z tokenem. Jeśli włączysz pobieranie i unieważnia tokenów dostępu OAuth 2.0 według identyfikatora aplikacji, to właśnie ten identyfikator będzie używany.
  • Pole access_token zawiera wartość tokena dostępu OAuth 2.0.

W domyślnym tokenie dostępu OAuth nie ma pola identyfikatora użytkownika. Aby umożliwić odzyskiwanie i odwoływanie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika, musisz skonfigurować zasadę OAuth 2.0, aby uwzględniała identyfikator użytkownika w tokenie. Aby to zrobić, wykonaj czynności opisane poniżej. Jeśli chcesz tylko pobierać i odwoływać tokeny dostępu OAuth 2.0 według identyfikatora aplikacji, nie musisz włączać dostępu według identyfikatora użytkownika.

Do punktu końcowego tworzenia tokena przekazujesz identyfikator użytkownika. Identyfikator użytkownika możesz przekazać jako parametr zapytania, parametr formularza lub w nagłówku (jak wyjaśniono dalej w tym temacie). Gdy skonfigurujesz Edge tak, aby zawierał w tokenie identyfikator użytkownika końcowego, będzie on uwzględniony w polu app_enduser, jak pokazano poniżej:

{
 "issued_at" : "1421847736581",
 "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
 "scope" : "READ",
 "app_enduser" : "6ZG094fgnjNf02EK",
 "status" : "approved",
 "api_product_list" : "[PremiumWeatherAPI]",
 "expires_in" : "3599", //--in seconds
 "developer.email" : "tesla@weathersample.com",
 "organization_id" : "0",
 "token_type" : "BearerToken",
 "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
 "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
 "organization_name" : "myorg",
 "refresh_token_expires_in" : "0", //--in seconds
 "refresh_count" : "0"
}

Aby dowiedzieć się, jak wykonywać wywołania interfejsu API, które umożliwiają odzyskiwanie i odwoływanie dostępu, zapoznaj się z tymi artykułami na temat Dokumentów inteligentnych:

Włączanie dostępu do tokenów OAuth 2.0 na podstawie identyfikatora użytkownika i identyfikatora aplikacji

Sposób włączania dostępu do tokenów OAuth 2.0 według identyfikatora użytkownika i identyfikatora aplikacji zależy od sposobu wdrożenia:

  • Wdrażanie w chmurze

    Wdrożenie usługi Edge w chmurze oznacza, że większość konfiguracji jest obsługiwana przez Apigee. Odpowiadasz tylko za skonfigurowanie zasad OAuth 2.0 w celu dodania identyfikatora użytkownika do tokena dostępu. Więcej informacji znajdziesz w procedurze poniżej.

  • Wdrażanie Edge for Private Cloud

    W przypadku Apigee Edge for Private Cloud (na urządzeniu lokalnym) ponosisz pełną odpowiedzialność za konfigurację. Więcej informacji znajdziesz w artykule Operacje i konfiguracja.

  • Apigee hybrydowy

    Domyślnie dostęp do tokenów OAuth 2.0 według identyfikatora użytkownika jest włączony. Odpowiadasz tylko za skonfigurowanie zasad OAuth 2.0 w celu dodania identyfikatora użytkownika do tokena dostępu. Więcej informacji znajdziesz w kroku 5 poniżej.

Włączanie dostępu w chmurze

Krok 1. Umożliw organizacji obsługę tej funkcji

Ta funkcja musi być włączona w każdej organizacji, w której chcesz ją obsługiwać.

Aby zaktualizować organizację, skontaktuj się z zespołem pomocy Apigee Edge.

Krok 2. Przypisz uprawnienia do zasobów oauth2 do ról „opsadmin” i „orgadmin”

Tylko role orgadmin i opsadmin powinny mieć uprawnienia do wykonywania tych wywołań metody „wyszukiwanie” (get) i „cofanie” (put) zasobu oauth2 na podstawie identyfikatora użytkownika lub identyfikatora aplikacji.

Aby sprawdzić, które role mają uprawnienia get i put do zasobu oauth2, możesz użyć wywołania interfejsu API GetPermission for a Resource.

Jeśli chcesz dodać lub usunąć uprawnienia, skontaktuj się z zespołem pomocy Apigee Edge, aby przeprowadził on aktualizacje.

Krok 3. Skopiuj istniejące tokeny dostępu OAuth 2.0 do węzłów Cassandra

Wykonane przez zespół pomocy Apigee: w tym zadaniu kopie dotychczasowych tokenów dostępu OAuth 2.0 w organizacjach, których dotyczy problem, zostaną skopiowane i zapisane w węzłach Cassandra. Ta procedura zostanie wykonana na węzłach Cassandra w przypadku każdego z Twoich podów Apigee Edge. Umożliwi to odzyskiwanie i odwoływanie wywołań interfejsu API, które są wykonywane przy użyciu wszystkich tokenów dostępu OAuth 2.0 (zarówno dotychczasowych, jak i nowo wygenerowanych).

Krok 4. Skonfiguruj zasadę OAuth 2.0, aby generować tokeny dostępu zawierające identyfikatory użytkowników

Skonfiguruj zasadę OAuth 2.0 używaną do generowania tokenów dostępu, aby uwzględnić identyfikator użytkownika w tokenie. Dzięki uwzględnieniu identyfikatorów użytkowników w tokenach dostępu możesz wykonywać operacje pobierania i odwoływania za pomocą identyfikatorów użytkowników.

Aby skonfigurować zasady tak, aby zawierały identyfikator użytkownika w tokenie dostępu, musisz określić zmienną wejściową zawierającą identyfikator użytkownika. Aby określić zmienną, użyj tagu <AppEndUser>.

Podana niżej zasada OAuth 2.0 o nazwie GenerateAccessTokenClient generuje token dostępu OAuth 2.0. Zwróć uwagę na dodanie pogrubionego tagu <AppEndUser>:

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessTokenClient">
  <DisplayName>OAuth 2.0.0 1</DisplayName>
  <ExternalAuthorization>false</ExternalAuthorization>
  <Operation>GenerateAccessToken</Operation>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GenerateResponse enabled="true"/>
  <GrantType>request.queryparam.grant_type</GrantType>
  <AppEndUser>request.header.appuserID</AppEndUser>
  <ExpiresIn>960000</ExpiresIn>
</OAuthV2>

Następnie możesz użyć poniższego polecenia cURL, aby wygenerować token dostępu OAuth 2.0, przekazując identyfikator użytkownika jako nagłówek appuserID:

curl -H "appuserID:6ZG094fgnjNf02EK" /
  https://myorg-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials /
  -X POST /
  -d 'client_id=k3nJyFJIA3p62TKIkLO6OJNi87GYXFmP&client_secret=gk58jK5lIp943AY4'

W tym przykładzie parametr appuserID jest przekazywany jako nagłówek żądania. Informacje w ramach żądania możesz przekazywać na wiele sposobów. Możesz na przykład:

  • Użyj zmiennej parametru formularza: request.formparam.appuserID.
  • Używanie zmiennej przepływu, która udostępnia identyfikator użytkownika