Implementowanie typu uwierzytelnienia kodu autoryzacji

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

Kod autoryzacji jest jednym z najczęściej używanych typów uwierzytelnienia OAuth 2.0. Autoryzacja to „trzyetapowa autoryzacja OAuth” konfiguracji. W tej konfiguracji użytkownik uwierzytelnia się się z serwerem zasobów i wyraża zgodę na dostęp aplikacji do chronionych zasobów bez ujawniania nazw użytkowników i haseł aplikacji klienckiej.

O tym temacie

Ten temat zawiera ogólny opis i omówienie typu uwierzytelnienia OAuth 2.0. i omawia, jak wdrożyć ten proces w Apigee Edge.

Wideo

Obejrzyj krótki film, aby dowiedzieć się, jak używać typu uwierzytelnienia OAuth 2.0 do zabezpieczenia swoich interfejsów API.

Przypadki użycia

Ten typ uwierzytelnienia jest przeznaczony dla aplikacji napisanych przez zewnętrznych deweloperów, którzy nie mieć zaufaną relację biznesową z dostawcą interfejsu API. Na przykład deweloperzy, którzy zarejestrują się publicznych programów API nie należy ogólnie traktować jako zaufane. W przypadku tego typu uwierzytelnienia użytkownik dane logowania na serwerze zasobów nigdy nie są udostępniane aplikacji.

Przykładowy kod

Pełną, działającą przykładową implementację typu uwierzytelnienia kodu autoryzacji znajdziesz na stronie Apigee Edge w repozytorium api-platform-samples na GitHubie. Zobacz oauth-advanced sample. Zobacz README, aby uzyskać szczegółowe informacje o próbce.

Schemat przepływu

Poniższy diagram przepływu ilustruje przepływ kodu autoryzacji OAuth w Apigee Edge który działa jako serwer autoryzacji.

Wskazówka: aby zobaczyć większą wersję tego diagramu, kliknij go prawym przyciskiem myszy i otwórz nową kartę lub zapisz ją i otwórz w przeglądarce obrazów.

Kroki w przepływie kodu autoryzacji

Oto podsumowanie czynności wymaganych do wdrożenia typu uwierzytelnienia kodu autoryzacji, w którym Apigee Edge działa jako serwer autoryzacji. Kluczem do tego procesu jest to, aby klient nigdy nie widzi danych logowania użytkownika na serwerze zasobów.

Warunek wstępny: aplikacja kliencka musi być zarejestrowana w Apigee Edge, aby uzyskać identyfikator klienta i klucze tajnego klienta. Patrz sekcja Rejestrowanie aplikacji klienckich dla: .

1. Użytkownik inicjuje proces

Gdy aplikacja musi uzyskać dostęp do zabezpieczonych zasobów użytkownika z serwera zasobów (na listy kontaktów w witrynie mediów społecznościowych), wysyła wywołanie interfejsu API do Apigee Edge, które sprawdza identyfikator klienta i, jeśli jest poprawny, przekierowuje przeglądarkę użytkownika na stronę logowania, na której użytkownik wpisze swoje dane logowania. Wywołanie interfejsu API zawiera informacje dotyczące aplikacji klienckiej uzyskane podczas rejestracji: identyfikator klienta i identyfikator URI przekierowania.

2. Użytkownik wpisuje dane logowania

Użytkownik widzi teraz stronę logowania, na której jest proszony o podanie danych logowania. Jeśli logowanie się powiedzie, przejdź do następnego kroku.

3. Użytkownik wyraża zgodę

W tym kroku użytkownik wyraża zgodę na dostęp aplikacji do zasobów. Formularz zgody zwykle obejmuje wybór zakresu, w którym użytkownik może wybrać, co aplikacja może robić na serwerze zasobów. Użytkownik może na przykład przyznać uprawnienie tylko do odczytu do aktualizacji zasobów.

4. Aplikacja do logowania wysyła żądanie Apigee Edge

Jeśli logowanie i wyrażenie zgody się powiedzie, aplikacja logowania wysyła dane do żądania POST w interfejsie /authorizationcode punktu końcowego Apigee Edge. Dane obejmują identyfikator URI przekierowania, identyfikator klienta, zakres oraz dowolne informacje, jakie ma zawierać, oraz informacja, że logowanie się powiodło.

5. Apigee Edge generuje kod autoryzacji.

Gdy Edge otrzyma żądanie GET z aplikacji logowania w punkcie końcowym /authorizationcode, dwa różne rzeczy. Najpierw Edge określa, czy logowanie było udane (sprawdzając stan HTTP lub w inny sposób). Next Edge sprawdza, czy identyfikator URI przekierowania został wysłany z aplikacji do logowania pasuje do identyfikatora URI przekierowania określonego podczas rejestrowania aplikacji w Apigee Edge. Jeśli wszystko jest w porządku, Edge generuje kod autoryzacji. Na przykład:

http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

6. Krawędź wysyła kod autoryzacji z powrotem do klienta,

Edge wysyła przekierowanie 302 z kodem autoryzacji dołączonym jako parametr zapytania do klienta.

7. Klient pobiera kod autoryzacji i prosi o kod dostępu z Edge

Teraz dzięki prawidłowemu kodowi autoryzacji klient może zażądać tokena dostępu z Edge. Robi to przez POST: typ i zakres uwierzytelnienia. Uwzględniając identyfikator klienta i klucze obiektu tajnego, które Apigee Edge może zweryfikować że aplikacja kliencka jest zarejestrowana. Na przykład:

$ curl https://{org_name}-test.apigee.net/my_oauth_proxy/accesstoken?code=Xyz123&grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpKNhGar6K&client_secret=hAr4GngA9vAyvI4'

8. Klient otrzymuje token dostępu

Jeśli wszystko się uda, Edge zwróci token dostępu klientowi. Token dostępu ma datę wygaśnięcia i będzie obowiązywać tylko w zakresie określonym przez użytkownika, wyrazić zgodę na dostęp aplikacji do jej zasobów.

9. Klient wywołuje metodę Protected API

Teraz klient może wywoływać chroniony interfejs API za pomocą prawidłowego kodu dostępu. W tym Scenariusze są wysyłane do Apigee Edge (serwera proxy), a Edge odpowiada za ich weryfikację token dostępu przed przekazaniem wywołania interfejsu API do docelowego serwera zasobów. Tokeny dostępu są przekazywane w nagłówku autoryzacji. Na przykład:

$ curl -H "Authorization: Bearer ylSkZIjbdWybfs4fUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

Konfigurowanie przepływów i zasad

Jako serwer autoryzacji Edge musi przetwarzać liczbę żądań OAuth: w celu uzyskania dostępu tokeny, kody autoryzacji, tokeny odświeżania, przekierowania na stronie logowania itp. Istnieją dwa podstawowe kroki skonfiguruj te punkty końcowe:

  • Tworzenie przepływów niestandardowych
  • Dodawanie i konfigurowanie zasad OAuthV2

Niestandardowa konfiguracja przepływu

Zwykle konfigurujesz przepływ tego typu uwierzytelnienia tak, że każdy krok lub „etap” jest zdefiniowany za pomocą procesu w serwerze proxy Apigee Edge. Każdy przepływ ma punkt końcowy i zasadę, która wykonuje Wymagane jest zadanie związane z protokołem OAuth, na przykład generowanie kodu autoryzacji lub tokena dostępu. Dla: jak pokazano w poniższym kodzie XML, punkt końcowy /oauth/authorizationcode ma parametr powiązane zasady o nazwie GenerateAuthCode (czyli zasady OAuthV2 z Podano operację GenerateAuthorizationCode).

Konfigurację przepływu najłatwiej pokazać na przykładzie pliku XML. Zobacz tekst w tekście komentarzy z informacjami o każdym procesie. Oto przykład: nazwy przepływów i ścieżek mogą można dowolnie skonfigurować. Zobacz też Konfigurowanie protokołu OAuth punktów końcowych i zasad, w których znajdziesz krótkie omówienie kroków niezbędnych do utworzenia niestandardowego przepływu. w ten sposób.

Zobacz też przykład implementacji w GitHubie. 

<Flows>
  <Flow name="RedirectToLoginApp">
         <!-- 
         Publish this URI to developers to use for their 'login' link 
         -->
    <Condition>proxy.pathsuffix == "/oauth/authorize"</Condition>
    <Request>
        <Step><Name>RedirectToLoginPage</Name></Step>
    </Request>
  </Flow>
  <Flow name="GetAuthCode">
         <!-- 
         Call this URL from your Login app after you authenticate the user.
         The policy will automatically return the auth code in the response to the 
         redirect_uri registered by the calling app 
         -->
    <Condition>proxy.pathsuffix == "/oauth/authorizationcode"</Condition>
    <Request>
        <Step><Name>GenerateAuthCode</Name></Step>
    </Request>
  </Flow>
  <Flow name="GetAccessToken">
         <!-- This policy flow is triggered when the URI path suffix
         matches /oauth/accesstoken. Publish this URL to app developers 
         to use when obtaining an access token using an auth code   
         -->
    <Condition>proxy.pathsuffix == "/oauth/accesstoken"</Condition>
    <Request>
        <Step><Name>GenerateAccessToken</Name></Step>
    </Request>
  </Flow>
</Flows>

Konfigurowanie przepływów przy użyciu zasad

Z każdym punktem końcowym powiązana jest zasada. Przyjrzyjmy się przykładowym zasadom. Zobacz również skonfigurowanie protokołu OAuth punktów końcowych i zasad, w którym znajdziesz krótkie omówienie czynności, które trzeba wykonać, aby dodać zasady OAuthV2. do punktów końcowych serwera proxy.

Przekierowanie logowania

To jest ścieżka /oauth/authorize. Dołączona zasada jest odpowiedzialna za przekierowania użytkownika do aplikacji logowania, gdzie może on bezpiecznie uwierzytelnić i autoryzować do uzyskiwania dostępu do chronionych zasobów bez konieczności podawania swojej nazwy użytkownika i hasła do aplikacji klienckiej. Możesz to zrobić za pomocą zasad dotyczących wywołań usługi, JavaScriptu, Node.js w inny sposób.

Wywołanie interfejsu API wysłane do żądania jest metodą GET, które wymaga parametru zapytania client_id, response_type, przekierowanie_uri, zakres i stan.

$ curl http://myorg-test.apigee.net/oauth/authorize?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

Uzyskaj kod autoryzacji

To jest ścieżka /oauth/authorizationcode. Wykorzystuje zasady OAuthV2 oraz Określono operację GenerateAuthorizationCode.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GetAuthCode">
    <DisplayName>GetAuthCode</DisplayName>
    <Operation>GenerateAuthorizationCode</Operation>
    <ExpiresIn>600000</ExpiresIn>
    <GenerateResponse/>
</OAuthV2>

Wywołanie interfejsu API w celu uzyskania kodu autoryzacji jest metodą GET i wymaga parametrów zapytania client_id, response_type oraz opcjonalnie zakresie i stanu, jak pokazano w tym przykładzie:

$curl http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&scope=scope1%20scope2&state={some_string}

Uzyskiwanie tokena dostępu

Ta zasada jest połączona ze ścieżką /oauth/accesstoken. Wykorzystuje protokół OAuthV2 zasadę z określoną operacją GenerateAccessCode. W tym przypadku parametr grant_type ma wartość oczekiwano w postaci parametru zapytania:

<OAuthV2 name="GetAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>360000000</ExpiresIn> 
    <SupportedGrantTypes> 
        <GrantType>authorization_code</GrantType> 
    </SupportedGrantTypes> 
    <GrantType>request.queryparam.grant_type</GrantType> 
    <GenerateResponse/> 
</OAuthV2>

Wywołanie interfejsu API w celu uzyskania kodu dostępu jest metodą POST i musi zawierać parametr client_id, client_secret [tajny_klient],grant_type=authorization_code oraz opcjonalnie zakres. Na przykład:

$ curl https://{org_name}-test.apigee.net/oauth/accesstoken?grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'

To tylko podstawowe podsumowanie. Przykład produkcyjny zawiera wiele innych zasad tworzyć adresy URL, przeprowadzać przekształcenia i wykonywać inne zadania. Zapoznaj się z przykładem na GitHubie, aby poznać na gotowym, działającym projekcie.

Dołączanie zasady weryfikacji tokena dostępu

Dołącz zasadę VerifyAccessToken (zasada OAuthV2 z operacją VerifyAccessToken) określony) na początku dowolnego przepływu, który uzyskuje dostęp do chronionego interfejsu API, aby został wykonany. za każdym razem, gdy przychodzi prośba o dostęp do zabezpieczonych zasobów. Sprawdzanie, czy każde żądanie ma token dostępu. W przeciwnym razie zwracany jest błąd. Podstawowe informacje znajdziesz w artykule Weryfikowanie tokenów dostępu. 

<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
    <DisplayName>VerifyAccessToken</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <SupportedGrantTypes/>
    <GenerateResponse enabled="true"/>
    <Tokens/>
</OAuthV2>

Wywoływanie chronionego interfejsu API

Aby wywołać interfejs API chroniony za pomocą zabezpieczeń OAuth 2.0, musisz przedstawić prawidłowy dostęp token. Prawidłowym wzorcem jest umieszczenie tokena w nagłówku autoryzacji w następujący sposób: Uwaga token dostępu jest też nazywany „tokenem okaziciela”. 

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Zobacz też Wysyłanie token dostępu.