Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Implementowanie typu uwierzytelnienia kodu autoryzacji

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

Kod autoryzacji jest jednym z najczęściej używanych typów uprawnień OAuth 2.0. Przepływ kodu autoryzacji to konfiguracja „trzyskładnikowego uwierzytelniania OAuth”. W tej konfiguracji użytkownik uwierzytelnia się na serwerze zasobów i wyraża zgodę na dostęp aplikacji do chronionych zasobów bez ujawniania nazwy użytkownika ani hasła aplikacji klienckiej.

O tym temacie

W tym artykule znajdziesz ogólny opis i omówienie przepływu typu uprawnień do korzystania z uwierzytelniania przez OAuth 2.0 oraz informacje o tym, jak zaimplementować ten przepływ w Apigee Edge.

Wideo

Obejrzyj krótki film, aby dowiedzieć się, jak zabezpieczyć interfejsy API za pomocą typu uprawnień autoryzacji OAuth 2.0.

Przypadki użycia

Ten typ autoryzacji jest przeznaczony dla aplikacji napisanych przez deweloperów zewnętrznych, którzy nie mają zaufanych relacji biznesowych z dostawcą interfejsu API. Na przykład deweloperzy, którzy rejestrują się w programach publicznych interfejsów API, nie powinni być traktowani jako zaufani. W przypadku tego typu autoryzacji dane logowania użytkownika na serwerze zasobów nigdy nie są udostępniane aplikacji.

Przykładowy kod

Kompletną, działającą przykładową implementację typu przyznawania kodu autoryzacji w Apigee Edge znajdziesz w repozytorium api-platform-samples na GitHubie. Zobacz przykład oauth-advanced w katalogu api-platform-samples/sample-proxies. Szczegółowe informacje o przykładzie znajdziesz w pliku README.

Diagram przepływu

Na diagramie poniżej przedstawiono przepływ OAuth z kodem autoryzacji, w którym Apigee Edge pełni rolę serwera autoryzacji.

Wskazówka: aby wyświetlić większą wersję tego diagramu, kliknij go prawym przyciskiem myszy i otwórz w nowej karcie lub zapisz go i otwórz w przeglądarce obrazów.

Kroki przepływu kodu autoryzacji

Poniżej znajdziesz podsumowanie kroków wymaganych do wdrożenia typu uwierzytelnienia przez kod autoryzacji, w którym Apigee Edge pełni rolę serwera autoryzacji. Pamiętaj, że kluczem do tego procesu jest to, że klient nigdy nie widzi danych logowania użytkownika na serwerze zasobów.

Wymaganie wstępne: aplikacja kliencka musi być zarejestrowana w Apigee Edge, aby uzyskać identyfikator klienta i tajne klucze klienta. Więcej informacji znajdziesz w sekcji Rejestrowanie aplikacji klienckich.

1. Użytkownik inicjuje przepływ

Gdy aplikacja potrzebuje dostępu do chronionych zasobów użytkownika z serwera zasobów (np. listy kontaktów w serwisie społecznościowym), wysyła wywołanie interfejsu API do Apigee Edge, który weryfikuje identyfikator klienta. Jeśli jest on prawidłowy, przekierowuje przeglądarkę użytkownika na stronę logowania, na której użytkownik wpisuje swoje dane logowania. Wywołanie interfejsu API zawiera informacje, które aplikacja kliencka uzyskała 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 wpisanie danych logowania. Jeśli logowanie się powiedzie, przejdziemy do następnego kroku.

3. Użytkownik wyraża zgodę

W tym kroku użytkownik wyraża zgodę na dostęp aplikacji do jego zasobów. Formularz zgody zwykle zawiera wybór zakresu, w którym użytkownik może określić, co aplikacja może robić na serwerze zasobów. Użytkownik może na przykład przyznać uprawnienia tylko do odczytu lub uprawnienia do aktualizowania zasobów przez aplikację.

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

Jeśli logowanie i zgoda się powiodą, aplikacja logowania wysyła dane do punktu końcowego /authorizationcode Apigee Edge. Dane te obejmują identyfikator URI przekierowania, identyfikator klienta, zakres, wszelkie informacje o użytkowniku, które chce uwzględnić, oraz informację o tym, że logowanie się powiodło.

5. Apigee Edge generuje kod autoryzacji

Gdy Edge otrzyma żądanie POST z aplikacji logowania w punkcie końcowym /authorizationcode, nastąpią 2 rzeczy. Najpierw Edge sprawdza, czy logowanie się powiodło (sprawdzając parametry lub nagłówki żądania pod kątem wskaźnika sukcesu). Następnie Edge sprawdza, czy identyfikator URI przekierowania wysłany z aplikacji logowania jest zgodny z identyfikatorem URI przekierowania określonym podczas rejestracji aplikacji w Apigee Edge. Jeśli wszystko jest w porządku, Edge wygeneruje kod autoryzacji.

{redirect_uri}?code={authorization_code}&state={some_string}

6. Klient pobiera kod autoryzacji i wysyła do Edge żądanie tokena dostępu.

Teraz, gdy klient ma prawidłowy kod autoryzacji, może poprosić Edge o token dostępu. W tym celu wysyła żądanie POST z identyfikatorem klienta i tajnym kluczem klienta (uzyskanymi podczas rejestracji aplikacji w Edge), kodem autoryzacji, typem przyznawanych uprawnień i zakresem. Dzięki uwzględnieniu identyfikatora klienta i kluczy tajnych Apigee Edge może sprawdzić, czy aplikacja kliencka jest tą, która została 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'

7. Klient otrzymuje token dostępu.

Jeśli wszystko przebiegnie prawidłowo, Edge zwróci klientowi token dostępu. Token dostępu wygasa i jest ważny tylko w zakresie określonym przez użytkownika, gdy wyraził on zgodę na dostęp aplikacji do jego zasobów.

8. Klient wywołuje chroniony interfejs API

Teraz, gdy klient ma prawidłowy token dostępu, może wywoływać chroniony interfejs API. W tym scenariuszu żądania są wysyłane do Apigee Edge (proxy), a Edge odpowiada za weryfikację tokena dostępu przed przekazaniem wywołania interfejsu API do serwera zasobów docelowych. 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ć wiele żądań OAuth: tokenów dostępu, kodów autoryzacji, tokenów odświeżania, przekierowań na stronę logowania itp. Aby skonfigurować te punkty końcowe, musisz wykonać 2 podstawowe czynności:

Tworzenie niestandardowych procesów
Dodawanie i konfigurowanie zasad OAuthV2

Konfiguracja niestandardowego przepływu

Zwykle konfigurujesz ten typ przyznawania uprawnień w taki sposób, aby każdy krok lub „etap” procesu był zdefiniowany przez przepływ w proxy Apigee Edge. Każdy przepływ ma punkt końcowy i zasady, które wykonują wymagane zadanie związane z OAuth, np. generowanie kodu autoryzacji lub tokena dostępu. Na przykład, jak pokazano w poniższym kodzie XML, punkt końcowy /oauth/authorizationcode ma powiązaną zasadę o nazwie GenerateAuthCode (czyli zasadę OAuthV2 z określoną operacją GenerateAuthorizationCode).

Najłatwiej przedstawić konfigurację przepływu za pomocą przykładu XML. Informacje o poszczególnych przepływach znajdziesz w komentarzach w tekście. To tylko przykład – nazwy ścieżek i przepływów możesz skonfigurować w dowolny sposób. Zapoznaj się też z artykułem Konfigurowanie punktów końcowych i zasad OAuth, w którym znajdziesz szybkie omówienie kroków potrzebnych do utworzenia niestandardowego procesu, takiego jak ten.

Zobacz też przykładową implementację 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 za pomocą zasad

Z każdym punktem końcowym są powiązane zasady. Przyjrzyjmy się przykładom zasad. Zapoznaj się też z artykułem Konfigurowanie punktów końcowych i zasad OAuth, w którym znajdziesz szybki przegląd czynności potrzebnych do dodania zasad OAuthV2 do punktów końcowych proxy.

To ścieżka /oauth/authorize. Załączona zasada odpowiada za przekierowanie użytkownika do aplikacji logowania, w której może on bezpiecznie uwierzytelnić się i autoryzować aplikację kliencką, aby uzyskać dostęp do chronionych zasobów bez ujawniania nazwy użytkownika i hasła. Możesz to zrobić za pomocą zasady wywołania usługi, JavaScriptu, Node.js lub innych środków.

Wywołanie interfejsu API do wysłania żądania to GET i wymaga parametrów zapytania client_id, response_type, redirect_uri, scope i state.

$ 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. Korzysta z zasad OAuthV2 z określoną 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 to żądanie POST, które wymaga przekazania w treści żądania jako parametrów formularza wartości client_id, response_type, redirect_uri oraz opcjonalnie scope i state, jak pokazano w tym przykładzie:

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

Uzyskiwanie tokena dostępu

Ta zasada jest powiązana ze ścieżką /oauth/accesstoken. Korzysta z zasad OAuthV2 z określoną operacją GenerateAccessToken. W tym przypadku parametr grant_type jest oczekiwany jako parametr 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 tokena dostępu to żądanie POST, które musi zawierać kod autoryzacji, client_id, client_secret, grant_type=authorization_code i opcjonalnie zakres. Na przykład:

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

To tylko podstawowe podsumowanie. Przykład produkcyjny zawiera wiele innych zasad dotyczących tworzenia adresów URL, przeprowadzania przekształceń i wykonywania innych zadań. Aby zobaczyć kompletny, działający projekt, zapoznaj się z przykładowym projektem w GitHubie.

Dołączanie zasady weryfikacji tokena dostępu

Dołącz zasadę VerifyAccessToken (zasadę OAuthV2 z określoną operacją VerifyAccessToken) na początku każdego przepływu, który uzyskuje dostęp do chronionego interfejsu API, aby była ona wykonywana za każdym razem, gdy nadejdzie żądanie chronionych zasobów. Sprawdzanie na brzegu sieci, czy każde żądanie ma prawidłowy token dostępu. W przeciwnym razie zwracany jest błąd. Podstawowe czynności 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 token dostępu. Prawidłowy wzorzec to umieszczenie tokena w nagłówku Authorization w ten 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 tokena dostępu.