Wysyłanie żądań tokenów dostępu i kodów autoryzacji

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

W tym temacie pokażemy, jak poprosić o tokeny dostępu i kody autoryzacji, skonfigurować OAuth 2.0 i skonfiguruj zasady dla każdego obsługiwanego uwierzytelnienia .

Przykładowy kod

Dla Twojej wygody omówione w tym temacie zasady i punkty końcowe są dostępne na stronie GitHub w projekcie oauth-doc-examples. w repozytorium Apigee api-platform-samples. Możesz wdrożyć przykładowy kod i spróbować przykładowe żądania wyświetlane w tym temacie. Więcej informacji znajdziesz w projekcie README.

Żądanie tokena dostępu: typ przyznania kodu autoryzacji

Ta sekcja wyjaśnia, jak zażądać tokena dostępu za pomocą typu przyznania kodu autoryzacji przepływu danych. Wprowadzenie do typów uwierzytelnienia OAuth 2.0 znajdziesz w artykule Introduction to OAuth 2.0 (Wprowadzenie do OAuth 2.0).

Przykład prośba

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' \
   -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
   -X POST 'https://docs-test.apigee.net/oauth/accesstoken' \
   -d 'code=I9dMGHAN&grant_type=authorization_code&redirect_uri=http://example-callback.com'

Wymagany

Domyślnie parametry te muszą mieć wartość x-www-form-urlencoded i należy je określić w parametrze treść żądania (jak pokazano w przykładzie powyżej); można jednak zmienić tę wartość domyślną konfigurując <GrantType>, <Code> oraz <RedirectUri> elementów dołączonej do zasady OAuthV2 Punkt końcowy: /accesstoken. Więcej informacji znajdziesz w artykule Zasady OAuthV2.

  • grant_type – musi mieć wartość. authorization_code
  • code – kod autoryzacji otrzymany z urządzenia /authorize. punktu końcowego (lub inną nazwę). Aby zażądać tokena dostępu w ramach autoryzacji procesu przyznawania kodu, musisz najpierw uzyskać kod autoryzacji. Zobacz sekcję Przesyłanie prośby o kod autoryzacji poniżej. Więcej informacji znajdziesz w artykule Wdrażanie typ przyznania kodu autoryzacji.
  • redirect_uri – musisz podać ten parametr, jeśli Parametr redirect_uri został uwzględniony w poprzednim żądaniu kodu autoryzacji. Jeśli parametr redirect_uri nie został uwzględniony w żądaniu kodu autoryzacji, Jeśli nie podasz tego parametru, zasada używa wartości adresu URL wywołania zwrotnego, została podana podczas rejestracji aplikacji dewelopera.

Opcjonalne

  • state – ciąg znaków, który zostanie odesłany wraz z odpowiedzią. Zwykle używane aby zapobiec atakom polegającym na fałszowaniu żądań z innych stron.
  • scope – umożliwia filtrowanie listy usług interfejsu API, w których występuje wartość można użyć wygenerowanego tokena. Szczegółowe informacje o zakresie znajdziesz w artykule o korzystaniu z zakresów OAuth2.

Uwierzytelnianie

Identyfikator klienta i tajny klucz klienta należy przekazać jako nagłówek uwierzytelniania podstawowego. (zakodowane w formacie Base64) lub jako parametry formularza client_id i client_secret. Ty uzyskać te wartości z zarejestrowanej aplikacji dewelopera. Więcej informacji znajdziesz w artykule „Podstawowe kodowanie” dane uwierzytelniające”.

Przykładowy punkt końcowy

Oto przykładowa konfiguracja punktu końcowego służąca do generowania tokena dostępu. Wykona Zasada GenerateAccessToken, która musi być skonfigurowana do obsługi przyznawania kodu autoryzacji typu.

...
       <Flow name="generate-access-token">
            <Description>Generate a token</Description>
            <Request>
                <Step>
                    <Name>GenerateAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/token") and (request.verb = "POST")</Condition>
        </Flow>
...

Przykładowa zasada

To jest podstawowa zasada GenerateAccessToken skonfigurowana tak, aby akceptowała authorization_code typ uwierzytelnienia. Informacje o opcjonalnych elementach konfiguracji które możesz skonfigurować przy użyciu tych zasad, zapoznaj się z sekcją Zasady OAuthV2.

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn>
    <RefreshTokenExpiresIn>86400000</RefreshTokenExpiresIn>
    <SupportedGrantTypes>
      <GrantType>authorization_code</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Zwroty

Gdy zasada <GenerateResponse> jest włączona, zasada zwraca odpowiedź JSON, która zawiera token dostępu, jak pokazano poniżej. Typ uwierzytelnienia authorization_code tworzy token dostępu i tokeny odświeżania, więc odpowiedź może wyglądać tak:

{
    "issued_at": "1420262924658",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420262924658",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "fYACGW7OCPtCNDEnRSnqFlEgogboFPMm",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "2l4IQtZXbn5WBJdL6EF7uenOWRsi",
    "organization_name": "docs",
    "refresh_token_expires_in": "86399", //--in seconds
    "refresh_count": "0"
}

Jeśli <GenerateResponse> ma wartość Fałsz, zasada nie zwraca . Zamiast tego wypełnia poniższy zestaw zmiennych przepływu danymi odnoszącymi się do token dostępu.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token
oauthv2accesstoken.{policy-name}.refresh_token_expires_in //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token_issued_at
oauthv2accesstoken.{policy-name}.refresh_token_status

Na przykład:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token
oauthv2accesstoken.GenerateAccessToken.refresh_token_expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token_issued_at
oauthv2accesstoken.GenerateAccessToken.refresh_token_status

Żądanie tokena dostępu: klient typ przyznania danych logowania

Z tej sekcji dowiesz się, jak zażądać tokena dostępu za pomocą typu przyznania danych logowania klienta przepływu danych. Wprowadzenie do typów uwierzytelnienia OAuth 2.0 znajdziesz w artykule Introduction to OAuth 2.0 (Wprowadzenie do OAuth 2.0).

Przykład prośba

Informacje o kodowaniu nagłówka podstawowego uwierzytelniania w poniższym wywołaniu znajdziesz w materiałach na temat „Kodowanie podstawowych danych uwierzytelniających”. 

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic c3FIOG9vSGV4VHoAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
  -X POST 'https://docs-test.apigee.net/oauth/accesstoken' \
  -d 'grant_type=client_credentials'

Wymagany

Domyślnie wymagany parametr Grants_type musi mieć wartość x-www-form-urlencoded i określone w treści żądania (jak pokazano w przykładzie powyżej); można jednak zmienić domyślnie, konfigurując element <GrantType> w zasadzie OAuthV2, która jest podłączony do tego punktu końcowego /accesstoken. Możesz na przykład przekazać w parametrze zapytania. Więcej informacji znajdziesz w artykule Zasady OAuthV2.

  • grant_type – musi mieć wartość. client_credentials

Opcjonalne

  • state – ciąg znaków, który zostanie odesłany wraz z odpowiedzią. Zwykle używane aby zapobiec atakom polegającym na fałszowaniu żądań z innych stron.
  • scope – umożliwia filtrowanie listy usług interfejsu API, w których występuje wartość można użyć wygenerowanego tokena. Szczegółowe informacje o zakresie znajdziesz w artykule o korzystaniu z zakresów OAuth2.

Uwierzytelnianie

Identyfikator klienta i tajny klucz klienta należy przekazać jako nagłówek uwierzytelniania podstawowego. (zakodowane w formacie Base64) lub jako parametry formularza client_id i client_secret Te wartości pochodzą z zarejestrowanej aplikacji dewelopera powiązane z żądaniem. Więcej informacji znajdziesz w sekcji „Kodowanie podstawowego uwierzytelniania”. dane logowania”.

Przykładowy punkt końcowy

Oto przykładowa konfiguracja punktu końcowego służąca do generowania tokena dostępu. Wykona Zasada GenerateAccessToken, która musi być skonfigurowana, aby obsługiwać uwierzytelnienie client_credentials typu.

...
       <Flow name="generate-access-token">
            <Request>
                <Step>
                    <Name>GenerateAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/token") and (request.verb = "POST")</Condition>
        </Flow>
...

Przykładowa zasada

To jest podstawowa zasada GenerateAccessToken skonfigurowana tak, aby akceptowała client_credentials typ uwierzytelnienia. Informacje o opcjonalnych elementach konfiguracji które możesz skonfigurować przy użyciu tych zasad, zapoznaj się z sekcją Zasady OAuthV2.

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <SupportedGrantTypes>
      <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Zwroty

Gdy zasada <GenerateResponse> jest włączona, zasada zwraca odpowiedź JSON. Notatka że z typem uwierzytelnienia client_credentials tokeny odświeżania nie są obsługiwane. Tylko token dostępu. Na przykład:

{
    "issued_at": "1420260525643",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "scope": "READ",
    "status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "XkhU2DFnMGIVL2hvsRHLM00hRWav",
    "organization_name": "docs"
}

Jeśli <GenerateResponse> ma wartość Fałsz, zasada nie zwraca . Zamiast tego wypełnia poniższy zestaw zmiennych przepływu danymi odnoszącymi się do token dostępu.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in //--in seconds

Na przykład:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in     //--in seconds

Żądanie tokena dostępu: typ przyznania hasła

Ta sekcja wyjaśnia, jak poprosić o token dostępu za pomocą hasła właściciela zasobu przepływ typu uwierzytelniania danych logowania (hasła). Wprowadzenie do typów uwierzytelnienia OAuth 2.0 znajdziesz w tych artykułach: Wprowadzenie do OAuth 2.0

Więcej informacji o typie przyznawania hasła, w tym 4-minutowy film pokazujący, jak jak go wdrożyć, można znaleźć w sekcji Implementowanie hasła

Przykład prośba

Informacje o kodowaniu nagłówka podstawowego uwierzytelniania w poniższym wywołaniu znajdziesz w materiałach na temat „Kodowanie podstawowych danych uwierzytelniających”. 

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
  -X POST https://docs-test.apigee.net/oauth/token \
  -d 'grant_type=password&username=the-user-name&password=the-users-password'

Wymagany

Domyślnie parametry te muszą mieć wartość x-www-form-urlencoded i należy je określić w parametrze treść żądania (jak pokazano w przykładzie powyżej); można jednak zmienić tę wartość domyślną konfigurując <GrantType>, <Username> oraz <Password> elementów dołączonej do zasady OAuthV2 Punkt końcowy: /token. Więcej informacji znajdziesz w artykule Zasady OAuthV2.

Dane logowania użytkownika są zwykle sprawdzane w magazynie danych logowania przy użyciu protokołu LDAP lub zasady JavaScript.

  • grant_type – musi mieć wartość password.
  • username – nazwa użytkownika właściciela zasobu;
  • password – hasło właściciela zasobu.

Opcjonalne

  • state – ciąg znaków, który zostanie odesłany wraz z odpowiedzią. Zwykle używane aby zapobiec atakom polegającym na fałszowaniu żądań z innych stron.
  • scope – umożliwia filtrowanie listy usług interfejsu API, w których występuje wartość można użyć wygenerowanego tokena. Szczegółowe informacje o zakresie znajdziesz w artykule o korzystaniu z zakresów OAuth2.

Uwierzytelnianie

Identyfikator klienta i tajny klucz klienta należy przekazać jako nagłówek uwierzytelniania podstawowego. (zakodowane w formacie Base64) lub jako parametry formularza client_id i client_secret Te wartości pochodzą z zarejestrowanej aplikacji dewelopera powiązane z żądaniem. Więcej informacji znajdziesz w sekcji „Kodowanie podstawowego uwierzytelniania”. dane logowania”.

Przykładowy punkt końcowy

Oto przykładowa konfiguracja punktu końcowego służąca do generowania tokena dostępu. Wykona Zasada GenerateAccessToken, która musi być skonfigurowana pod kątem obsługi typu przyznawania hasła.

...
       <Flow name="generate-access-token">
            <Request>
                <Step>
                    <Name>GenerateAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/token") and (request.verb = "POST")</Condition>
        </Flow>
...

Przykładowa zasada

To jest podstawowa zasada GenerateAccessToken skonfigurowana tak, aby akceptowała uwierzytelnienie hasła typu. Informacje o opcjonalnych elementach konfiguracji, które można skonfigurować za pomocą tej zasady, Więcej informacji: Zasady OAuthV2.

<OAuthV2 name="GenerateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <RefreshTokenExpiresIn>28800000</RefreshTokenExpiresIn> <!-- 8 hours -->
    <SupportedGrantTypes>
      <GrantType>password</GrantType>
    </SupportedGrantTypes>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Zwroty

Gdy zasada <GenerateResponse> jest włączona, zasada zwraca odpowiedź JSON. Notatka że przy typie uwierzytelnienia hasłem generowany jest zarówno token dostępu, jak i token odświeżania. Dla: przykład:

{
    "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", //--in seconds
    "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": "28799", //--in seconds
    "refresh_count": "0"
}

Jeśli <GenerateResponse> ma wartość Fałsz, zasada nie zwraca . Zamiast tego wypełnia poniższy zestaw zmiennych przepływu danymi odnoszącymi się do token dostępu.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in   //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token
oauthv2accesstoken.{policy-name}.refresh_token_expires_in  //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token_issued_at
oauthv2accesstoken.{policy-name}.refresh_token_status

Na przykład:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token
oauthv2accesstoken.GenerateAccessToken.refresh_token_expires_in
oauthv2accesstoken.GenerateAccessToken.refresh_token_issued_at
oauthv2accesstoken.GenerateAccessToken.refresh_token_status

Żądanie tokena dostępu: niejawne uwierzytelnienie typ

W tej sekcji wyjaśniono, jak zażądać tokena dostępu za pomocą przepływu niejawnego typu uwierzytelnienia. Dla: Wprowadzenie do typów uwierzytelnienia OAuth 2.0 znajdziesz we wprowadzeniu do OAuth 2.0.

Przykład prośba

$ curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \
  'https://docs-test.apigee.net/oauth/implicit?response_type=token&client_id=ABC123&redirect_uri=http://callback-example.com'

Wymagany

Domyślnie te parametry muszą być parametrami zapytania (jak pokazano w przykładzie powyżej). jednak można zmienić tę wartość domyślną, konfigurując <ResponseType>, Elementy <ClientId> i <RedirectUri> w protokole OAuthV2 która jest dołączona do tego punktu końcowego /token. Więcej informacji znajdziesz w artykule Zasady OAuthV2.

Dane logowania użytkownika są zwykle sprawdzane w magazynie danych logowania przy użyciu usługi LDAP. lub zasad JavaScript.

  • response_type – musi mieć wartość token.
  • client_id – identyfikator klienta zarejestrowanej aplikacji dewelopera.
  • redirect_uri – ten parametr jest wymagany, jeśli identyfikator URI wywołania zwrotnego nie został użyty podana podczas rejestrowania aplikacji dewelopera klienta. Jeśli na kliencie podano adres URL wywołania zwrotnego rejestracji, zostanie ona porównana z tą wartością i musi dokładnie odpowiadać.

Opcjonalne

  • state – ciąg znaków, który zostanie odesłany wraz z odpowiedzią. Zwykle używane aby zapobiec atakom polegającym na fałszowaniu żądań z innych stron.
  • scope – umożliwia filtrowanie listy usług interfejsu API, w których występuje wartość można użyć wygenerowanego tokena. Szczegółowe informacje o zakresie znajdziesz w artykule o korzystaniu z zakresów OAuth2.

Uwierzytelnianie

Uwierzytelnienie pośrednie nie wymaga podstawowego uwierzytelniania. Należy przekazać identyfikator klienta jako zgodnie z tym opisem.

Przykładowy punkt końcowy

Oto przykładowa konfiguracja punktu końcowego służąca do generowania tokena dostępu. Wykona Zasada GenerateAccessTokenImplicitGrant.

...
       <Flow name="generate-access-token-implicit">
            <Request>
                <Step>
                    <Name>GenerateAccessTokenImplicitGrant</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/implicit") and (request.verb = "POST")</Condition>
        </Flow>
...

Przykładowa zasada

To jest podstawowa zasada GenerateAccessTokenImplicitGrant, która przetwarza żądania tokenów dla przepływ niejawnego uwierzytelnienia. Informacje o opcjonalnych elementach konfiguracji, które możesz skonfigurować za pomocą tej zasady, zapoznaj się z artykułem na temat zasad OAuthV2.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 name="GenerateAccessTokenImplicit">
    <DisplayName>GenerateAccessTokenImplicit</DisplayName>
    <Operation>GenerateAccessTokenImplicitGrant</Operation>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Zwroty

Gdy zasada <GenerateResponse> jest włączona, zasada zwraca kod przekierowania 302 (lokalizacja) w nagłówku odpowiedzi. Przekierowanie wskazuje adres URL podany w polu redirect_uri i zawiera on informację o czasie ważności tokena. Pamiętaj, że niejawne typ uwierzytelnienia nie obsługuje tokenów odświeżania. Na przykład:

https://callback-example.com#expires_in=1799&access_token=In4dKm4ueoGZRbIYJhC9yZCmTFw5

Jeśli <GenerateResponse> ma wartość Fałsz, zasada nie zwraca . Zamiast tego wypełnia poniższy zestaw zmiennych przepływu danymi odnoszącymi się do token dostępu.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in  //--in seconds

Na przykład:

oauthv2accesstoken.GenerateAccessToken.access_token
oauthv2accesstoken.GenerateAccessToken.expires_in   //--in seconds

Żądanie kodu autoryzacji

Jeśli korzystasz z przepływu typu przyznania kodu autoryzacji, musisz uzyskać autoryzację przed wysłaniem żądania o token dostępu.

Przykładowe żądanie

$ curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \
  'http://myorg-test.apigee.net/oauth/authorize?client_id={consumer_key}&response_type=code'

gdzie do elementu zamówienia jest podłączona zasada GenerateAuthorizationCode OAuthV2 Punkt końcowy serwera proxy /oauth/authorize (zobacz przykładowy punkt końcowy poniżej).

Wymagany

Domyślnie te parametry muszą być parametrami zapytania (jak pokazano w przykładzie powyżej). jednak można zmienić tę wartość domyślną, konfigurując <ResponseType>, Elementy <ClientId> i <RedirectUri> w protokole OAuthV2 która jest dołączona do tego punktu końcowego /authorize. Więcej informacji znajdziesz w artykule Zasady OAuthV2.

  • response_type – musi mieć wartość code.
  • client_id – identyfikator klienta zarejestrowanej aplikacji dewelopera.

Opcjonalne

  • redirect_uri – jeśli pełny (nieczęściowy) identyfikator URI wywołania zwrotnego został określony w w przypadku zarejestrowanej aplikacji klienta, ten parametr jest opcjonalny; w przeciwnym razie jest wymagane. Wywołanie zwrotne to adres URL, na który Edge wysyła nowo wygenerowany kod autoryzacji. Przeczytaj też artykuł Rejestrowanie aplikacji i zarządzanie interfejsem API .
  • state – ciąg znaków, który zostanie odesłany wraz z odpowiedzią. Zwykle używane aby zapobiec atakom polegającym na fałszowaniu żądań z innych stron.
  • scope – umożliwia filtrowanie listy usług interfejsu API, w których występuje wartość można użyć wygenerowanego tokena. Szczegółowe informacje o zakresie znajdziesz w artykule o korzystaniu z zakresów OAuth2.

Uwierzytelnianie

Nie wymaga podstawowego uwierzytelniania, ale musi mieć identyfikator klienta zarejestrowanej aplikacji klienckiej .

Przykładowy punkt końcowy

Przykładowa konfiguracja punktu końcowego służąca do generowania kodu autoryzacji:


<OAuthV2 name="GenerateAuthorizationCode">
  <Operation>GenerateAuthorizationCode</Operation>
    <!--
    ExpiresIn, in milliseconds. The ref is optional. The explicitly specified
    value is the default, when the variable reference cannot be resolved.
        60000 = 1 minute
       120000 = 2 minutes
    -->
  <ExpiresIn>60000</ExpiresIn>
  <GenerateResponse enabled="true"/>
</OAuthV2>

Przykładowa zasada

To jest podstawowa zasada GenerateAuthorizationCode. Informacje o opcjonalnej konfiguracji elementy, które można skonfigurować za pomocą tych zasad, zawiera artykuł Zasady OAuthV2.

<OAuthV2 name="GenerateAuthorizationCode">
    <Operation>GenerateAuthorizationCode</Operation>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Zwroty

Gdy zasada <GenerateResponse> jest włączona, zasada zwraca wartość ?code do lokalizacji redirect_uri (Callback URI) z autoryzacją z kodem. Jest ona wysyłana przez przekierowanie 302 przeglądarki z adresem URL umieszczonym w nagłówku Location tagu . Na przykład: ?code=123456.

Jeśli <GenerateResponse> ma wartość false, zasada nie zwrócić odpowiedź. Zamiast tego wypełnia poniższy zestaw zmiennych przepływu danymi odnoszącymi się do do kodu autoryzacji.

oauthv2authcode.{policy-name}.code
oauthv2authcode.{policy-name}.scope
oauthv2authcode.{policy-name}.redirect_uri
oauthv2authcode.{policy-name}.client_id

Na przykład:

oauthv2authcode.GenerateAuthorizationCode.code
oauthv2authcode.GenerateAuthorizationCode.scope
oauthv2authcode.GenerateAuthorizationCode.redirect_uri
oauthv2authcode.GenerateAuthorizationCode.client_id

Odświeżanie tokena dostępu

Token odświeżania to dane logowania używane do uzyskania tokena dostępu, zwykle po token utracił ważność lub stanie się nieważny. Token odświeżania jest zwracany w odpowiedzi, gdy otrzymasz token dostępu.

Aby poprosić o nowy token dostępu przy użyciu tokena odświeżania:

Przykładowe żądanie

Informacje o kodowaniu nagłówka podstawowego uwierzytelniania w poniższym wywołaniu znajdziesz w materiałach na temat „Kodowanie podstawowych danych uwierzytelniających”. 

$ curl -X POST \
  -H "Content-type: application/x-www-form-urlencoded" \
  -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAyg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
  https://myorg-test.apigee.net/my_oauth_endpoint/refresh_accesstoken \
  -d 'grant_type=refresh_token&refresh_token=my-refresh-token'

Parametry wymagane

  • grant_type – musi mieć wartość refresh_token.
  • refresh_token – token odświeżania powiązany z Twoim tokenem dostępu które chcesz odnowić.

Domyślnie zasada szuka ich jako parametrów x-www-form-urlencoded określone w treści żądania, jak widać w powyższym przykładzie. Konfigurowanie alternatywnej lokalizacji dla tych danych wejściowych możesz użyć funkcji <GrantType> i <RefreshToken> elementów w zasadzie OAuthV2. Więcej informacji znajdziesz w artykule Zasady OAuthV2.

Parametry opcjonalne

  • state – ciąg znaków, który zostanie odesłany wraz z odpowiedzią. Zwykle używane aby zapobiec atakom polegającym na fałszowaniu żądań z innych stron.
  • scope – umożliwia filtrowanie listy usług interfejsu API, w których występuje wartość można użyć wygenerowanego tokena. Szczegółowe informacje o zakresie znajdziesz w artykule o korzystaniu z zakresów OAuth2.

Uwierzytelnianie

  • client_id
  • client_secret

Identyfikator klienta i tajny klucz klienta należy przekazać jako nagłówek uwierzytelniania podstawowego. (zakodowane w formacie Base64) lub jako parametry formularza client_id i client_secret. Zobacz a także „Kodowanie podstawowych danych uwierzytelniających”.

Po odświeżeniu tokena dostępu nie następuje ponowne uwierzytelnienie użytkownika.

Oto przykładowa konfiguracja punktu końcowego służąca do generowania tokena dostępu przy użyciu tokena odświeżania. Wykona ona zasadę RefreshAccessToken.

 ...
       <Flow name="generate-refresh-token">
            <Request>
                <Step>
                    <Name>RefreshAccessToken</Name>
                </Step>
            </Request>
            <Response/>
            <Condition>(proxy.pathsuffix MatchesPath "/refresh") and (request.verb = "POST")</Condition>
       </Flow>
...

Przykładowa zasada

To jest podstawowa zasada RefreshAccessToken skonfigurowane tak, aby akceptowała refresh_token typ uwierzytelnienia. Informacje o opcjonalnych elementach konfiguracji, które które możesz skonfigurować za pomocą tej zasady, zapoznaj się z sekcją Zasady OAuthV2.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 name="RefreshAccessToken">
    <Operation>RefreshAccessToken</Operation>
    <GenerateResponse enabled="true"/>
    <ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
    <RefreshTokenExpiresIn>28800000</RefreshTokenExpiresIn> <!-- 8 hours -->
</OAuthV2>

Zwroty

Gdy zasada <GenerateResponse> jest włączona, zasada zwraca odpowiedź JSON który zawiera nowy token dostępu. Typ uwierzytelnienia refresh_token obsługuje tworzenie zarówno i nowych tokenów odświeżania. Na przykład:

{
    "issued_at": "1420301470489",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "scope": "READ",
    "refresh_token_issued_at": "1420301470489",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799", //--in seconds
    "developer.email": "tesla@weathersample.com",
    "token_type": "BearerToken",
    "refresh_token": "8fKDHLryAD9KFBsrpixlq3qPJnG2fdZ5",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "jmZ2Hqv3iNsABUtAAsfWR3QGNctw",
    "organization_name": "docs",
    "refresh_token_expires_in": "28799", //--in seconds
    "refresh_count": "2"
}

Pamiętaj, że po wygenerowaniu nowego tokena odświeżania oryginał utracił ważność.

Powyższą odpowiedź otrzymasz, jeśli zasada <GenerateResponse> ma wartość Prawda. Jeśli zasada <GenerateResponse> ma wartość Fałsz, zasada nie zwraca odpowiedzi. Zamiast tego wypełnia poniższy zestaw zmiennych kontekstowych (przepływu) danymi odnoszącymi się do token dostępu.

oauthv2accesstoken.{policy-name}.access_token
oauthv2accesstoken.{policy-name}.expires_in   //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token
oauthv2accesstoken.{policy-name}.refresh_token_expires_in  //--in seconds
oauthv2accesstoken.{policy-name}.refresh_token_issued_at
oauthv2accesstoken.{policy-name}.refresh_token_status

Na przykład:

oauthv2accesstoken.RefreshAccessToken.access_token
oauthv2accesstoken.RefreshAccessToken.expires_in
oauthv2accesstoken.RefreshAccessToken.refresh_token
oauthv2accesstoken.RefreshAccessToken.refresh_token_expires_in
oauthv2accesstoken.RefreshAccessToken.refresh_token_issued_at
oauthv2accesstoken.RefreshAccessToken.refresh_token_status

Kodowanie podstawowe dane uwierzytelniające

Wywołanie interfejsu API w celu żądania tokena lub kodu uwierzytelniania jest dobrą metodą. zalecane przez specyfikację OAuth 2.0, aby przekazywać wartości client_id i client_secret's jako nagłówek uwierzytelniania podstawowego HTTP zgodnie z opisem w dokumencie IETF RFC 2617. Aby to zrobić, zakodować wynik połączenia dwóch wartości, oddzielając je dwukropkiem.

W pseudokodzie:

result = Base64Encode(concat('ns4fQc14Zg4hKFCNaSzArVuwszX95X', ':', 'ZIjFyTsNgQNyxI'))

W tym przykładzie ns4fQc14Zg4hKFCNaSzArVuwszX95X to identyfikator klienta, ZIjFyTsNgQNyxI to tajny klucz klienta.

Niezależnie od języka programowania używanego do obliczania wartości zakodowanej w formacie base64 – dla tych z danymi logowania klienta, wynik zakodowany w formacie base64 będzie wyglądał tak: bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==

Następnie możesz wysłać żądanie tokena w następujący sposób:

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==' \
  -X POST 'https://docs-test.apigee.net/oauth/accesstoken' \
  -d 'grant_type=client_credentials'

Narzędzie curl utworzy dla Ciebie podstawowy nagłówek HTTP, jeśli użyjesz opcję -u. Ten fragment jest odpowiednikiem powyższego:

$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' \
  -u 'ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI' \
  -X POST 'https://docs-test.apigee.net/oauth/accesstoken' \
  -d 'grant_type=client_credentials'

Inne środowiska programistyczne mogą mieć podobne skróty, które automatycznie generują zakodowany w formacie base64.

Haszowanie tokenów w bazie danych

Aby chronić dostęp OAuth i tokeny odświeżania w przypadku naruszenia bezpieczeństwa bazy danych, możesz: włączyć automatyczne szyfrowanie tokenów w organizacji Edge. Gdy ta funkcja jest włączona, Edge automatycznie tworzy zahaszowaną wersję nowo wygenerowanych dostępu OAuth i tokenów odświeżania przy użyciu na określonym algorytmie. (Poniżej znajdziesz informacje o szyfrowaniu masowym istniejących tokenów). niezaszyfrowane tokeny są używane w wywołaniach interfejsu API, a Edge weryfikuje je pod kątem zahaszowanych wersji w w bazie danych.

Poniższe właściwości na poziomie organizacji kontrolują szyfrowanie tokenów OAuth.

features.isOAuthTokenHashingEnabled = true
features.OAuthTokenHashingAlgorithm = SHA1 | SHA256 | SHA384 | SHA512 | PLAIN

Jeśli masz już zaszyfrowane tokeny i chcesz je przechowywać do czasu ich wygaśnięcia, ustaw parametr poniższe właściwości w organizacji, gdzie algorytm szyfrowania pasuje do (na przykład SHA1 – poprzednia wartość domyślna Edge). Jeśli tokeny nie zostały zahaszowane, użyj PLAIN.

features.isOAuthTokenFallbackHashingEnabled = true
features.OAuthTokenFallbackHashingAlgorithm = SHA1 | SHA256 | SHA384 | SHA512 | PLAIN

Jeśli jesteś klientem Edge w chmurze, skontaktuj się z zespołem pomocy Apigee Edge, aby skonfigurować te w swojej organizacji oraz opcjonalnie zahaszować istniejące tokeny.

Powiązane artykuły