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

Korzystanie z tokenów OAuth innych firm

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

W tej części omówimy importowanie zewnętrznie wygenerowanych tokenów dostępu, tokenów odświeżania i kodów autoryzacji do magazynu tokenów Edge. Możesz użyć tej metody, jeśli chcesz skonfigurować Apigee Edge pod kątem weryfikowania tokenów wygenerowanych poza Apigee Edge.

W zwykłym przypadku Apigee Edge wygeneruje i zapisze token OAuth, a następnie zwróci go do aplikacji wywołującej. Aplikacja wywołująca prezentuje ten token z powrotem Apigee Edge podczas żądania usługi, a Apigee Edge – za pomocą zasady OAuthV2 z operacji = VerifyAccessToken – sprawdzi, czy token jest prawidłowy. W tym temacie opisujemy, jak skonfigurować Apigee Edge w celu przechowywania tokena OAuth, który został wygenerowany w innym miejscu, przy czym część weryfikacji tokena nie ulegnie zmianie, tak jakby token został wygenerowany przez Edge.

Przykład

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

Co to jest?

Załóżmy, że masz istniejący system autoryzacji i chcesz używać wartości tokena lub kodu wygenerowanego przez ten system zamiast tokena OAuth2 lub wartości kodu generowanych przez Edge. Następnie możesz wysyłać żądania bezpiecznych serwerów proxy do interfejsu API z podstawionym tokenem lub kodem, a Edge zweryfikuje je tak, jakby zostały wygenerowane przez Edge.

Niektóre informacje

W zwykłym przypadku Apigee Edge generuje token przez losowy ciąg liter i cyfr. Apigee Edge wiąże się z tym tokenem. Inne dane, takie jak czas wystawienia tokena, data wygaśnięcia, lista usług API, dla których token jest prawidłowy, oraz zakres. Wszystkie te informacje mogą zostać zwrócone w odpowiedzi automatycznie wygenerowanej przez zasadę OAuthV2 skonfigurowaną z 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 rzeczywistości kluczem wyszukiwania danych odpowiedzi. Aplikacja może wysłać żądanie do serwera proxy interfejsu API hostowanego w Edge, używając tokena okaziciela zBC90HhCGmGlaMBWeZAai2s3za5j, a Edge – z zasadą OAuthV2 z operacji = VerifyAccessToken – wyszuka token, pobierze wszystkie informacje i użyje tych informacji do określenia, czy token jest prawidłowy dla żądanego serwera proxy interfejsu API. Jest to tzw. weryfikacja tokena. Na token składają się wszystkie powyższe informacje. Wartość „access_token” służy jedynie do wyszukiwania tych informacji.

Z drugiej strony, wykonując czynności opisane w tym artykule, możesz skonfigurować Edge tak, aby zapisywała token, tak aby jego wartość access_token była generowana przez usługę zewnętrzną. Wszystkie inne metadane mogą być takie same. Załóżmy na przykład, że masz system spoza Apigee Edge, który generuje tokeny w formie „TOKEN-<16 losowych liczb>”. W takim przypadku pełne metadane tokena przechowywane przez Apigee Edge mogą mieć postać:

{
  "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 tym przypadku aplikacja może wysłać żądanie do serwera proxy interfejsu API hostowanego w Edge, niosąc token okaziciela TOKEN-1092837373654221, a Edge – za pomocą zasady OAuthV2 z operacji =VerifyAccessToken – zostanie zweryfikowana. Podobny wzorzec importu możesz zastosować do kodów autoryzacji i tokenów odświeżania.

Porozmawiajmy o weryfikowaniu danych logowania klienta

Jednym z wymagań wstępnych do wygenerowania tokena jest weryfikacja klienta żądającego. Domyślnie zasada OAuthV2/GenerateAccessToken w Apigee Edge pośrednio weryfikuje dane logowania klienta. Standardowo w żądaniu tokena OAuthV2 identyfikatory client_id i client_secret są przekazywane w nagłówku Authorization, zakodowane za pomocą podstawowej autoryzacji HTTP (dwukropek, a następnie zakodowany w base64). Zasada OAuthV2/GenerateAccessToken w Apigee Edge dekoduje ten nagłówek, wyszukuje identyfikator client_id oraz sprawdza, czy przekazany klucz klienta jest prawidłowy dla tego identyfikatora client_id. Działa to, jeśli dane logowania są znane Apigee Edge. Inaczej mówiąc, w Apigee Edge znajduje się aplikacja programisty, która zawiera dane logowania, które zawierają dane client_id i client_secret.

Jeśli dane logowania klienta nie mają być sprawdzane przez Apigee Edge, musisz zaprojektować serwer proxy interfejsu API, zanim wygeneruje token, aby wyraźnie weryfikować klienta za pomocą innych sposobów. Często jest to za pomocą zasady ServiceCallout, która łączy się ze zdalnym punktem końcowym w Twojej sieci.

W ten sposób, pośrednio lub bezpośrednio, musisz upewnić się, że serwer proxy interfejsu API, który generuje tokeny, weryfikuje najpierw dane logowania klienta. Pamiętaj, że weryfikacja klienta jest niezależna od wygenerowania tokena dostępu. Możesz skonfigurować Apigee Edge tak, aby wykonywała obie te czynności, obie te usługi lub obie te usługi.

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 pomiń go całkowicie. Jeśli chcesz używać zewnętrznej usługi autoryzacji do jawnego weryfikowania danych logowania klienta, ustaw <ExternalAuthorization> na true.

Mimo że Apigee Edge może nie weryfikować danych logowania klienta, nadal musi znać identyfikator client_id i zarządzać nim. Każdy token dostępu w Apigee Edge, niezależnie od tego, czy został wygenerowany przez Apigee Edge lub wygenerowany przez system zewnętrzny, a następnie zaimportowany do Apigee Edge, musi być powiązany z aplikacją kliencką, co wskazuje identyfikator client_id. Dlatego nawet jeśli zasada OAuthV2/GenerateAccessToken w Apigee Edge nie sprawdzi, czy parametry client_id i client_secret są zgodne, zasada sprawdzi, czy identyfikator client_id jest prawidłowy, istnieje i nie został unieważniony. W ramach wstępnego etapu konfiguracji konieczne może być zaimportowanie identyfikatorów client_id za pomocą administracyjnego interfejsu API Edge.

Przepływ zasad dotyczących protokołu OAuth innej firmy w Apigee

Aby można było używać tokenów z zewnętrznych systemów OAuth w Apigee Edge, proces generowania tokenów dostępu powinien być zgodny z jednym z poniższych wzorców.

Zewnętrzna weryfikacja danych logowania klienta

ServiceCallout, aby zweryfikować dane logowania klienta przychodzącego i uzyskać token zewnętrzny.
ExtractVariables lub krok JavaScript, aby wyodrębniać token wygenerowany zewnętrznie z odpowiedzi.
AssignMessage pozwala 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 elementem <ExternalAuthorization> ustawionym na true i co najmniej jedną z tych wartości: <ExternalAccessToken>, <ExternalRefreshToken> lub <ExternalAuthorizationCode>.

Wewnętrzna weryfikacja danych logowania klienta

ServiceCallout, aby uzyskać token zewnętrzny.
ExtractVariables lub krok JavaScript, aby wyodrębniać token wygenerowany zewnętrznie z odpowiedzi.
OAuthV2/GenerateAccessToken z elementem <ExternalAuthorization> ustawionym na false i co najmniej jedną z tych wartości: <ExternalAccessToken>, <ExternalRefreshToken> lub <ExternalAuthorizationCode>.

Uwagi na temat konfiguracji procesu i zasad

Jeśli do weryfikacji danych logowania klienta chcesz używać zewnętrznego systemu, musisz opracować proces zasad, który spełni jego potrzeby. Zwykle do wysyłania rozpoznanych zewnętrznie danych logowania do zewnętrznej usługi uwierzytelniania należy używać zasady ServiceCallout. Zewnętrzna usługa uwierzytelniania zwykle zwraca odpowiedź, a jeśli dane logowania są prawidłowe, także token dostępu.
Po wystąpieniu usługi ServiceCallout serwer proxy interfejsu API musi przeanalizować odpowiedź, aby wyodrębnić stan ważności, a także wygenerowany zewnętrznie token dostępu (access_token) i ewentualnie token odświeżania.
W zasadzie OAuthV2/GenerateAccessToken ustaw element <StoreToken> na true, a element <ExternalAuthorization> ustaw na true lub false.

Gdy zasada OAuthV2/GenerateAccessToken zostanie uruchomiona, odczytuje zmienną oauth_external_authorization_status. Jeśli zmienna jest ustawiona, a wartość to prawda, Apigee Edge nie próbuje zweryfikować danych logowania klienta. Jeśli zmienna nie jest ustawiona lub wartość jest nieprawidłowa, Apigee Edge spróbuje zweryfikować dane logowania klienta.
Zasada OAuthV2 ma 3 elementy, które umożliwiają określenie zewnętrznych danych 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 lub kod autoryzacji. Musisz wdrożyć zasady i logikę, aby umieścić zewnętrzne tokeny lub kody w odpowiednich zmiennych.

Na przykład ta konfiguracja w zasadzie OAuthV2 powoduje, że przeglądarka Edge szuka tokena w zmiennej kontekstowej o nazwie external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Musisz też mieć poprzedni krok ustawiający tę zmienną.

Jeśli chodzi o ustawienie zmiennej oauth_external_authorization_status, typową metodą ustawiania tej zmiennej jest użycie zasady AssignMessage z elementem AssignVariable:

<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 znaleźć się przed zasadą OAuthV2 z operacji = GenerateAccessToken.

Przykładowa zasada OAuthV2

Poniższa zasada OAuthV2 generuje token dostępu Apigee Edge, ponieważ Edge znajduje wartość tokena 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>

Normalnie w przypadku typu uwierzytelnienia danych logowania klienta należy podać nagłówek uwierzytelniania podstawowego z zakodowanym identyfikatorem klienta i tajnym kluczem klienta. W tym przypadku nie musisz podawać tego nagłówka. Zasada nadal oczekuje, że element client_id będzie obecny w żądaniu, a zasada go sprawdzi. Edge oczekuje, że client_id będzie wysyłany jako część danych formularza żądania, np. w elemencie request.formparam.client_id.

Teoretycznie można zastosować ten wzorzec w dowolnej zewnętrznej usłudze autoryzacji OAuth2.