Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Korzystanie z tokenów OAuth innych firm

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

Z tego artykułu dowiesz się, jak importować wygenerowane zewnętrznie tokeny dostępu, tokeny odświeżania, lub kody autoryzacji do magazynu tokenów Edge. Możesz użyć tej techniki, jeśli chcesz skonfigurować Apigee Edge tak, aby weryfikował tokeny generowane poza Apigee Edge.

Zwykle Apigee Edge generuje i przechowuje token OAuth oraz zwraca go do aplikacji wywołującej. Aplikacja wywołująca przedstawia ten token z powrotem w Apigee Edge, gdy żąda usługi, a Apigee Edge – za pomocą zasady OAuthV2 z ustawieniem Operation = VerifyAccessToken – sprawdza, czy token jest prawidłowy. Z tego artykułu dowiesz się, jak skonfigurować Apigee Edge tak, aby przechowywał token OAuth wygenerowany w innym miejscu, zachowując tę samą część weryfikacji tokena, jakby token został wygenerowany przez Edge.

Przykład

Jeśli chcesz zobaczyć działający przykład ilustrujący technikę opisaną w tym artykule, zapoznaj się z przykładem zarządzania tokenami delegowanymi w Apigee.

Co to jest?

Załóżmy, że masz już system autoryzacji i chcesz używać wartości tokenów lub kodów generowanych przez ten system zamiast wartości tokenów lub kodów OAuth2 generowanych przez Edge. Możesz wtedy wysyłać bezpieczne żądania proxy interfejsu API z zastąpionym tokenem lub kodem, a Edge będzie je weryfikować tak, jakby zostały wygenerowane przez Edge.

Informacje ogólne

Zwykle Apigee Edge generuje token, tworząc losowy ciąg liter i cyfr. Apigee Edge łączy z tym tokenem inne dane, takie jak czas wydania tokena, jego ważność, lista usług API, dla których token jest ważny, oraz zakres. Wszystkie te informacje mogą być zwracane w odpowiedzi automatycznie generowanej przez zasadę OAuthV2 skonfigurowaną z ustawieniem Operation = 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 rzeczywistości kluczem wyszukiwania danych odpowiedzi. Aplikacja może wysłać żądanie do proxy interfejsu API hostowanego w Edge, zawierające token okaziciela zBC90HhCGmGlaMBWeZAai2s3za5j, a Edge – za pomocą zasady OAuthV2 z ustawieniem Operation = VerifyAccessToken – wyszuka token, pobierze wszystkie informacje i użyje ich, aby określić, czy token jest prawidłowy w przypadku żądanego proxy interfejsu API. Nazywa się to weryfikacją tokena. Wszystkie powyższe informacje składają się na token. Wartość access_token to tylko sposób na wyszukanie tych informacji.

Z drugiej strony, wykonując opisane tu czynności, możesz skonfigurować Edge tak, aby przechowywał token, którego access_token wartość jest generowana przez usługę zewnętrzną. Wszystkie inne metadane mogą być takie same. Załóżmy na przykład, że masz system zewnętrzny względem Apigee Edge, który generuje tokeny w formacie "TOKEN-<16 losowych liczb>" . 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 proxy interfejsu API hostowanego w Edge, zawierające token okaziciela TOKEN-1092837373654221, a Edge – za pomocą zasady OAuthV2 z ustawieniem Operation = VerifyAccessToken – będzie mógł je zweryfikować. Podobny wzorzec importu możesz zastosować do kodów autoryzacji i tokenów odświeżania.

Weryfikowanie danych logowania klienta

Jednym z warunków wstępnych wygenerowania tokena jest zweryfikowanie klienta wysyłającego żądanie. Domyślnie zasada OAuthV2/GenerateAccessToken w Apigee Edge niejawnie weryfikuje dane logowania klienta. Zwykle w żądaniu tokena OAuthV2 identyfikator klienta i tajny klucz klienta są przekazywane w nagłówku Authorization zakodowanym za pomocą podstawowego uwierzytelniania HTTP (połączone dwukropkiem, a następnie zakodowane w formacie base64). Zasada OAuthV2/GenerateAccessToken w Apigee Edge dekoduje ten nagłówek i wyszukuje identyfikator klienta i sprawdza, czy przekazany tajny klucz klienta jest prawidłowy w przypadku tego identyfikatora. Działa to, jeśli dane logowania są znane Apigee Edge – innymi słowy, w Apigee Edge jest przechowywana aplikacja dewelopera, która zawiera dane logowania, a te dane logowania zawierają podany identyfikator klienta i tajny klucz klienta.

Jeśli dane logowania klienta nie mają być weryfikowane przez Apigee Edge, musisz zaprojektować proxy interfejsu API tak, aby przed wygenerowaniem tokena wyraźnie weryfikował klienta za pomocą innych środków. Często odbywa się to za pomocą zasady ServiceCallout, która łączy się ze zdalnym punktem końcowym w Twojej sieci.

W ten czy inny sposób, niejawnie lub jawnie, musisz się upewnić, że proxy interfejsu API które generuje tokeny, najpierw weryfikuje dane logowania klienta. Pamiętaj, że weryfikacja klienta jest niezależna od generowania tokena dostępu. Możesz skonfigurować Apigee Edge tak, aby wykonywał obie te czynności, tylko jedną z nich lub żadną.

Jeśli chcesz, aby zasada OAuthV2/GenerateAccessToken w Apigee Edge weryfikowała dane logowania klienta w magazynie Edge, ustaw element <ExternalAuthorization> na false w konfiguracji zasady lub całkowicie go pomiń. Jeśli chcesz użyć zewnętrznej usługi autoryzacji do wyraźnego zweryfikowania danych logowania klienta, ustaw <ExternalAuthorization> na true.

Chociaż Apigee Edge może nie weryfikować danych logowania klienta, identyfikator klienta musi być znany i zarządzany przez Apigee Edge. Każdy token access_token w Apigee Edge, niezależnie od tego, czy został wygenerowany przez Apigee Edge, czy przez system zewnętrzny, a następnie zaimportowany do Apigee Edge, musi być powiązany z aplikacją kliencką – wskazuje na to identyfikator client_id. Dlatego nawet w przypadku gdy zasada OAuthV2/GenerateAccessToken w Apigee Edge nie będzie sprawdzać, czy identyfikator client_id i tajny klucz client_secret są zgodne, zasada sprawdzi, czy identyfikator client_id jest prawidłowy, obecny i nie został unieważniony. W związku z tym w ramach konfiguracji wstępnej może być konieczne zaimportowanie identyfikatorów client_id za pomocą administracyjnego interfejsu API Edge.

Proces zasad w przypadku OAuth innych firm w Apigee

Aby używać tokenów z systemów OAuth innych firm w Apigee Edge, proces generowania tokenów dostępu powinien być zgodny z jednym z tych wzorców.

Zewnętrzna weryfikacja danych logowania klienta

ServiceCallout aby zweryfikować przychodzące dane logowania klienta i uzyskać token zewnętrzny.
ExtractVariables lub JavaScript, aby wyodrębnić token wygenerowany zewnętrznie z odpowiedzi.
AssignMessage, aby ustawić specjalną, dobrze znaną zmienną o nazwie oauth_external_authorization_status. Wartość musi być równa true, aby wskazywać, że dane logowania klienta są prawidłowe.
OAuthV2/GenerateAccessToken z elementem <ExternalAuthorization> ustawionym na true oraz co najmniej jednym z elementów <ExternalAccessToken>, <ExternalRefreshToken> lub <ExternalAuthorizationCode>.

Wewnętrzna weryfikacja danych logowania klienta

ServiceCallout aby uzyskać token zewnętrzny.
ExtractVariables lub JavaScript, aby wyodrębnić token wygenerowany zewnętrznie z odpowiedzi.
OAuthV2/GenerateAccessToken z elementem <ExternalAuthorization> ustawionym na false oraz co najmniej jednym z elementów <ExternalAccessToken>, <ExternalRefreshToken> lub <ExternalAuthorizationCode>.

Uwagi dotyczące konfiguracji procesu i zasad

Jeśli chcesz użyć systemu zewnętrznego do weryfikowania danych logowania klienta, musisz opracować proces zasad, który wykona niezbędne czynności. Zwykle używasz zasady ServiceCallout, aby wysłać dane logowania rozpoznawane przez system zewnętrzny do zewnętrznej usługi uwierzytelniania. Zewnętrzna usługa uwierzytelniania zwykle zwraca odpowiedź i, jeśli dane logowania są prawidłowe, także token dostępu.
Po wykonaniu ServiceCallout proxy interfejsu API musi przeanalizować odpowiedź, aby wyodrębnić stan ważności, a także token access_token wygenerowany zewnętrznie i ewentualnie token refresh_token.
W zasadzie OAuthV2/GenerateAccessToken ustaw element <StoreToken> na true, a element <ExternalAuthorization> na true lub false w zależności od potrzeb.

Gdy zasada OAuthV2/GenerateAccessToken jest wykonywana, odczytuje zmienną oauth_external_authorization_status. Jeśli zmienna jest ustawiona, a jej wartość to true, Apigee Edge nie próbuje weryfikować danych logowania klienta. Jeśli zmienna nie jest ustawiona lub jej wartość nie jest równa true, Apigee Edge spróbuje zweryfikować dane logowania klienta
W zasadzie OAuthV2 są 3 elementy, które umożliwiają określenie danych zewnętrznych do zaimportowania: <ExternalAccessToken>, <ExternalRefreshToken>, i <ExternalAuthorizationCode>. Każdy z tych elementów akceptuje zmienną przepływu. Zasada Edge odczyta tę zmienną, aby znaleźć token dostępu, token odświeżania lub kod autoryzacji wygenerowany zewnętrznie. Musisz zaimplementować zasady i logikę, aby umieścić tokeny lub kody zewnętrzne w odpowiednich zmiennych.

Na przykład ta konfiguracja w zasadzie OAuthV2 informuje Edge, aby szukał tokena w zmiennej kontekstowej o nazwie external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Musisz też mieć poprzedni krok, który ustawia tę zmienną.

Jeśli chodzi o ustawianie zmiennej oauth_external_authorization_status, typową techniką jest użycie zasady AssignMessage z elementem AssignVariable, np. tak:

<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 znajdować się przed zasadą OAuthV2 z ustawieniem Operation = GenerateAccessToken.

Przykładowa zasada OAuthV2

Ta zasada OAuthV2 generuje token dostępu Apigee Edge, jeśli Edge znajdzie wartość tokena w zmiennej procesu 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 w przypadku typu przyznania danych logowania klienta musisz podać nagłówek podstawowego uwierzytelniania z zakodowanym identyfikatorem klienta i tajnym kluczem klienta. W tym przypadku nie musisz jednak podawać tego nagłówka. Zasada nadal oczekuje, że w żądaniu będzie obecny client_id, i zasada będzie go weryfikować. Edge oczekuje, że client_id zostanie wysłany jako część danych formularza żądania, np. w request.formparam.client_id.

Teoretycznie możesz zastosować ten wzorzec w przypadku dowolnej usługi autoryzacji OAuth2 innej firmy.