Ta strona została przetłumaczona przez Cloud Translation API.

Korzystanie z tokenów OAuth innych firm

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

W tym temacie omówimy, jak importować zewnętrznie wygenerowane tokeny dostępu, tokeny odświeżania lub kody autoryzacji do magazynu tokenów brzegowych. Możesz użyć tej techniki, jeśli chcesz: Skonfiguruj Apigee Edge, aby weryfikować tokeny generowane poza Apigee Edge.

W normalnym przypadku Apigee Edge wygeneruje i zapisze token OAuth oraz zwróci go do aplikację wywołującą. Następnie aplikacja wywołująca prezentuje ten token z powrotem Apigee Edge przy wysyłaniu żądań a Apigee Edge przez zasadę OAuthV2 z operacjami = VerifyAccessToken aby sprawdzić, czy token jest prawidłowy. W tym temacie opisujemy, jak skonfigurować Apigee Edge do przechowywania token OAuth, który został wygenerowany w innym miejscu, zachowując część weryfikacji tokena: tak, jakby token został wygenerowany przez Edge.

Przykład

Jeśli chcesz zobaczyć praktyczny przykład ilustrujący daną metodę opisanych w tym temacie, obejrzyj narzędzie Apigee Przykład usługi delegowanej usługi Token Management.

Co to jest?

Załóżmy, że masz już system autoryzacji i chcesz korzystać z karty tokenem lub wartościami kodu wygenerowanymi przez ten system zamiast wartości tokena OAuth2 lub wartości kodu, Edge jest generowana. Możesz wtedy wysyłać żądania do bezpiecznego serwera proxy API za pomocą podstawionego tokena lub kodu, a Edge zweryfikuje je tak, jakby zostały wygenerowane przez Edge.

Kontekst

W typowym przypadku Apigee Edge generuje token, tworząc losowy ciąg liter i liczby. Apigee Edge wiąże się z tym tokenem, inne dane, takie jak data wydania tokena. daty ważności, listy Usług API, dla których token jest prawidłowy, oraz zakresu. Wszystko to informacje mogą być zwracane w odpowiedzi wygenerowanej automatycznie przez zasadę OAuthV2 skonfigurowana za pomocą operacji = GenerateAccessToken. Odpowiedź wygląda tak:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

Wartość atrybutu access_token jest w praktyce kluczem wyszukiwania dla: do danych odpowiedzi. Aplikacja może wysłać żądanie do serwera proxy interfejsu API hostowanego w Edge, z tokenem okaziciela zBC90HhCGmGlaMBWeZAai2s3za5j i Edge – z protokołem OAuthV2 zasad z operacjami = VerifyAccessToken – wyszuka token, pobierze wszystkie informacje i użyć tych informacji do określenia, czy token jest prawidłowy dla żądanego serwera proxy interfejsu API. Jest to tzw. weryfikacja tokena. Token składa się ze wszystkich podanych wyżej informacji. dostęp_token to po prostu sposób na znalezienie tych informacji.

Wykonując opisane tu czynności, możesz skonfigurować w Edge przechowywanie tak, by jego wartość access_token była generowana przez posprzedażna. Wszystkie pozostałe metadane mogą być takie same. Załóżmy na przykład, że masz system zewnętrzny względem Apigee Edge, która generuje tokeny w formacie „TOKEN-<16 losowych” numery>" , W takim przypadku pełne metadane tokena przechowywane przez Apigee Edge mogą wyglądać tak:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

W takim przypadku aplikacja może wysłać żądanie do serwera proxy interfejsu API hostowanego w Edge, przenosząc token TOKEN-1092837373654221 i Edge – przez zasadę OAuthV2 z operacjam = VerifyAccessToken będzie mieć możliwość weryfikacji. Podobny wzorzec importowania można zastosować do z kodami autoryzacji i tokenami odświeżania.

Porozmawiajmy o weryfikacji klienta Dane uwierzytelniające

Jednym z wymagań wstępnych do wygenerowania tokena jest weryfikacja klienta, który wysłał żądanie. Domyślnie atrybut Zasada OAuthV2/GenerateAccessToken w Apigee Edge domyślnie weryfikuje dane logowania klienta. Normalnie w żądaniu tokena OAuthV2 wartości client_id i client_secret (tajny klucz klienta) są przekazywane w funkcji Nagłówek autoryzacji zakodowany przy użyciu podstawowej autoryzacji HTTP (z dwukropkiem, ciąg zakodowanych w formacie base64). Zasada OAuthV2/GenerateAccessToken w Apigee Edge dekoduje ten nagłówek i wyszukuje parametr client_id i sprawdza, czy przekazany tajny klucz klienta jest prawidłowy; client_id. Działa to, jeśli dane logowania są znane Apigee Edge. Inaczej mówiąc, Aplikacja dewelopera przechowywana w Apigee Edge, która zawiera dane logowania, które same w sobie zawierają o wartości client_id i client_secret [tajny_klucz klienta]).

Jeśli Apigee Edge nie weryfikuje danych logowania klienta, musisz zaprojektuj serwer proxy interfejsu API, zanim wygeneruje token, aby jawnie zweryfikować klienta za pomocą w inny sposób. Często jest to spowodowane przez zasady ServiceCallout, które łączy się ze zdalnym punktem końcowym w Twojej sieci.

W dowolny sposób, pośrednio lub bezpośrednio, musisz się upewnić, że serwer proxy interfejsu API który generuje tokeny, najpierw weryfikuje dane logowania klienta. Pamiętaj, że weryfikacja jest niezależny od generowania tokena dostępu. Możesz skonfigurować Apigee Edge tak, aby wykonywał obie te czynności, albo wybrać jedno z tych rozwiązań.

Jeśli chcesz, aby zasada OAuthV2/GenerateAccessToken w Apigee Edge była weryfikowana przez klienta dane logowania do magazynu brzegowego, ustaw element <ExternalAuthorization> na false w konfiguracji zasady lub całkowicie go pomiń. Jeśli chcesz użyć tagu zewnętrznej usługi autoryzacji, aby jawnie zweryfikować dane logowania klienta, ustaw <ExternalAuthorization> do true.

Chociaż Apigee Edge może nie zweryfikować danych logowania klienta, w przypadku Identyfikator client_id, który ma być znany Apigee Edge i nią zarządzać. Każdy token dostępu w Apigee Edge, niezależnie od tego, wygenerowane przez Apigee Edge lub wygenerowane przez system zewnętrzny, a następnie zaimportowane do Apigee Edge musi być powiązana z aplikacją kliencką wskazywaną przez parametr client_id. Dlatego nawet w przypadku tego, w którym zasada OAuthV2/GenerateAccessToken w Apigee Edge nie sprawdza, czy parametr client_id i Client_secret (tajny klucz klienta), zasada sprawdza, czy identyfikator client_id jest prawidłowy, obecny i nie zawiera odwołany. Na etapie wstępnej konfiguracji konieczne może być zaimportowanie identyfikatorów client_id za pomocą Edge administracyjnego interfejsu API.

Przepływ zasad dla zewnętrznego protokołu OAuth w Apigee

Korzystanie z tokenów z systemów OAuth innych firm w Apigee Edge tokeny powinny być zgodne z jednym z poniższych wzorców.

Zewnętrzni Weryfikacja danych logowania klienta

ServiceCallout aby zweryfikować przychodzące dane logowania klienta i uzyskać token zewnętrzny.
ExtractVariables lub Krok JavaScript do wyodrębnienie tokena wygenerowanego zewnętrznie z odpowiedzi.
AssignMessage do ustawić specjalną, dobrze znaną zmienną o nazwie oauth_external_authorization_status. Wartość musi mieć wartość „true” (prawda), aby wskazywać, że dane logowania klienta są prawidłowe.
OAuthV2/GenerateAccessToken z wartością <ExternalAuthorization> element został ustawiony na true i co najmniej 1 z <ExternalAccessToken>, <ExternalRefreshToken> lub <ExternalAuthorizationCode>

Wewnętrzny Weryfikacja danych logowania klienta

ServiceCallout aby uzyskać token zewnętrzny.
ExtractVariables lub Krok JavaScript do wyodrębnienie tokena wygenerowanego zewnętrznie z odpowiedzi.
OAuthV2/GenerateAccessToken z wartością <ExternalAuthorization> element został ustawiony na false i co najmniej 1 z <ExternalAccessToken>, <ExternalRefreshToken> lub <ExternalAuthorizationCode>

Uwagi na temat konfiguracji przepływu i zasad

Jeśli do weryfikacji danych logowania klienta chcesz używać systemu zewnętrznego, do Ciebie należy stworzyć przepływ zasad, który spełni Twoje oczekiwania. Trzeba użyć zwykle Zasady dotyczące objaśnienia usługi służą do wysyłania rozpoznanych zewnętrznie danych logowania do systemu zewnętrznego uwierzytelniania. Zewnętrzne uwierzytelnianie zazwyczaj zwraca odpowiedź oraz token dostępu (jeśli dane logowania są prawidłowe).
Po zakończeniu objaśnienia usługi serwer proxy interfejsu API musi przeanalizować odpowiedź, aby wyodrębnić stanu ważności, a także zewnętrznie wygenerowany token dostępu refresh_token.
W zasadzie OAuthV2/GenerateAccessToken ustaw element <StoreToken> na true, a element <ExternalAuthorization> ustaw na true lub false.

Przy wykonywaniu zasady OAuthV2/GenerateAccessToken odczytuje zmienną oauth_external_authorization_status Jeśli zmienna jest ustawiona, a wartość to true, Apigee Edge nie podejmie próby weryfikacji danych logowania klienta. Jeśli zmienna nie jest ustawiona lub wartość jest nieprawidłowa, Apigee Edge spróbuje zweryfikować klienta dane logowania.
Zasada OAuthV2 ma 3 elementy, które umożliwiają określenie dane do zaimportowania: <ExternalAccessToken>, <ExternalRefreshToken>, i <ExternalAuthorizationCode>. Każdy z tych elementów akceptuje zmienną przepływu. Zasada Edge odczyta tę zmienną, aby znaleźć wygenerowany zewnętrznie token dostępu, token odświeżania czy kod autoryzacji. To Ty decydujesz, zaimplementuj zasady i logikę, aby umieścić zewnętrzne tokeny lub kody w odpowiednich zmiennych.

Na przykład ta konfiguracja w zasadzie OAuthV2 mówi Edge, aby szukała w zmiennej kontekstowej o nazwie external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Trzeba też mieć wcześniejszy krok, który ustawia tę zmienną.

Przy ustawianiu zmiennej oauth_external_authorization_status najczęstsza Aby ustawić tę zmienną, należy użyć zasady AssignMessage z w elemencie AssignZmienna:

<AssignMessage name="AssignMessage-SetVariable">
    <DisplayName>Assign Message - Set Variable</DisplayName>
    <AssignVariable>
        <Name>oauth_external_authorization_status</Name>
        <Value>true</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

Pamiętaj, że ta zasada musi być przed zasadą OAuthV2 z operację = GenerateAccessToken.

Przykładowa zasada OAuthV2

tych zasad OAuthV2, generuje token dostępu Apigee Edge, jeśli Edge znajduje w zmiennej przepływu external_access_token.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

Zwykle przy pomocy klienta typ uwierzytelnienia danych logowania, musisz podać nagłówek uwierzytelniania podstawowego za pomocą zakodowanego klienta Identyfikator i tajny klucz klienta. W tym przypadku nie musisz jednak podawać tych danych nagłówek. Zgodnie z zasadami nadal w żądaniu musi znajdować się atrybut client_id, a polecenie zasady weryfikacji. Edge oczekuje, że w ramach części zostanie wysłana karta client_id danych z formularza prośby, np. request.formparam.client_id.

Teoretycznie możesz zastosować ten wzorzec z dowolną autoryzacją OAuth2 innej firmy posprzedażna.