OAuth

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

Protokół OAuth staje się popularnym protokołem autoryzacji dla interfejsów API. Wersja omówionego szczegółowo w tym temacie protokołu OAuth, jest zdefiniowany w protokole OAuth. 2.0 Specyfikacja.

OAuth to protokół, który umożliwia użytkownikom aplikacji autoryzowanie aplikacji do działania w ich imieniu. Aplikacje uzyskują dostęp tokeny od dostawców interfejsów API. Dostawca interfejsu API uwierzytelnia koniec aplikacji dane logowania użytkownika, upewnij się, że użytkownik autoryzował aplikację, a potem wystawia token dostępu do aplikacji. Gdy aplikacja używa chronionego interfejsu API, Apigee Edge sprawdza token dostępu, aby upewnić się, że jest on ważny i nie stracił ważności. Jako dostawca interfejsu API musisz udostępnić punkty końcowe które umożliwiają aplikacjom uzyskiwanie tokenów dostępu.

Apigee Edge ułatwia rozpoczęcie korzystania z protokołu OAuth. umożliwia konfigurowanie i egzekwowanie protokołu OAuth za pomocą zasadbez konieczności wykonywania przez Ciebie nie pisać żadnego kodu. Z tej części dowiesz się, jak chronić swoje interfejsy API i jak uzyskać dostęp oraz sposoby korzystania z nich do uzyskiwania dostępu do chronionych interfejsów API.

Domyślna konfiguracja OAuth dla Twojego organizacja

Dla wygody wszystkie organizacje korzystające z Apigee Edge mają wstępnie skonfigurowany zestaw OAuth 2.0 punktów końcowych, które implementują typ przyznawania danych logowania klienta. Klient typ przyznania danych logowania definiuje procedurę wydawania tokenów dostępu w zamian za aplikację dane logowania. Dane logowania do aplikacji to po prostu para klucza klienta i tajnego klucza, która Problemy z Apigee Edge dotyczące każdej aplikacji zarejestrowanej w organizacji. Dane logowania klienta odnosi się do samej pary klucza klienta i hasła.

Więcej informacji o przyznawaniu danych logowania do aplikacji za pomocą usług dla programistów Edge znajdziesz tutaj Rejestrowanie aplikacji i zarządzanie kluczami

Z tego powodu można dość łatwo przejść na wyższy poziom, schemat zabezpieczeń interfejsu API z klucza interfejsu API weryfikacji danych logowania klienta OAuth. Oba schematy używają tego samego klucza klienta i tego samego tajnego klucza do weryfikować aplikację kliencką. Różnica polega na tym, że dane logowania klienta zapewniają dodatkową warstwę ponieważ można łatwo unieważnić token dostępu w razie potrzeby bez konieczności klucz klienta aplikacji. Aby pracować z domyślnymi punktami końcowymi OAuth, możesz użyć dowolnego klucza klienta i tajny klucz wygenerowany dla aplikacji w organizacji w celu pobierania tokenów dostępu z tokena. punktu końcowego. (Możesz nawet włączyć dane logowania klienta dla aplikacji, które mają już klucze klientów secrets.)

Pełną specyfikację przyznawania danych logowania klienta można znaleźć w dokumencie OAuth 2.0 Specyfikacja.

Chroń interfejs API za pomocą zasad

Aby korzystać z tokenów dostępu, musisz skonfigurować interfejsy API pod kątem weryfikacji dostępu OAuth tokeny w czasie działania. W tym celuskonfigurujesz serwer proxy interfejsu API, zweryfikować tokeny dostępu. Oznacza to, że za każdym razem, gdy aplikacja wysyła żądanie jeden z interfejsów API, aplikacja musi wraz z żądaniem API przedstawić prawidłowy token dostępu. Apigee Edge zajmuje się generowaniem, przechowywaniem i weryfikowaniem tokenów dostępu. dostępnych online.

Podczas tworzenia możesz łatwo dodać do interfejsu API weryfikację OAuth nowego serwera proxy API. Podczas tworzenia nowego serwera proxy interfejsu API możesz dodać funkcje. Jako jak pokazano poniżej, możesz dodać weryfikację tokenów dostępu OAuth 2.0, zaznaczając opcję obok pozycji Zabezpiecz się za pomocą tokenów dostępu OAuth 2.0. Po wybraniu tej opcji dwa zasady zostaną dołączone do nowo utworzonego serwera proxy interfejsu API, jedna w celu weryfikacji tokenów dostępu, a druga może usunąć token dostępu po jego zweryfikowaniu.

Oprócz tego jeśli wybierzesz opcję Zabezpiecz się dzięki tokenom dostępu OAuth w wersji 2.0, pole wyboru Opublikuj produkt API staje się możliwe do zaznaczenia i automatycznie zaznaczono. Zaznacz tę opcję, jeśli chcesz automatycznie generować produkt podczas tworzenia nowego interfejsu API. serwera proxy. Automatycznie wygenerowany produkt zostanie utworzony wraz z nowym serwerem proxy interfejsu API. Jeśli masz już usługę, z którą chcesz powiązać ten nowy interfejs API. Usuń zaznaczenie aby nie tworzyć zbędnych produktów. Informacje o produktach znajdziesz tutaj: Co to jest usługa API?

Jeśli musisz włączyć weryfikację tokena dostępu dla serwera proxy API który już istnieje, wystarczy tylko dołączyć do interfejsu API zasady typu OAuthV2 które chcą chronić. Zasady OAuthV2 określają operację. Jeśli chcesz w celu weryfikacji tokenów dostępu określasz operację o nazwie VerifyAccessToken. (Inne rodzaje operacji, które są obsługiwane przez typy zasad OAuthV2 to GenerateAccessToken i GenerateRefreshToken. Operacje te poznasz po skonfigurowaniu punktów końcowych OAuth).

Zasada VerifyOAuthTokens typu OAuthV2

Przykładowa zasada walidacji tokenów dostępu wygląda tak. (Te ustawienia są w tabeli poniżej).

<OAuthV2 name="VerifyOAuthTokens"> 
  <Operation>VerifyAccessToken</Operation> 
</OAuthV2>

Ustawienia zasad

Aby utworzyć tę zasadę w interfejsie zarządzania, otwórz Interfejsy API > Interfejs API Serwery proxy

Z listy serwerów proxy API wybierz Weatherapi.

Na stronie Podsumowanie w sekcji Weatherapi wybierz Dla deweloperów widok.

Z menu wybierz Nowa zasada > OAuth 2.0

Gdy wybierzesz zasadę OAuth 2.0, zobaczysz menu konfiguracji Nowa zasada .

Nadaj zasadom opisową nazwę i wybierz Dołącz zasadę. Flow PreFlow i Request (Żądanie) jako ustawienia załącznika zasad.

Wybierz Dodaj, a zasada zostanie utworzona i dołączona do żądania do interfejsu Weatherapi PreFlow.

Gdy dodasz tę zasadę, wymieniona poniżej konfiguracja PreFlow będzie wyświetlana w Panel projektanta.

Jeśli pracujesz lokalnie w edytorze tekstu lub w IDE, dołączasz plik zasady żądania PreFlow serwera proxy interfejsu API, który chcesz chronić:

<PreFlow>
  <Request>
    <Step><Name>VerifyOAuthTokens</Name></Step>
  </Request>
</PreFlow>

Dołączając zasadę do żądania PreFlow, masz pewność, że zasada jest zawsze egzekwowana we wszystkich wiadomościach z prośbami.

Udało Ci się zabezpieczyć interfejs API za pomocą danych logowania klienta OAuth 2.0. Dowiedz się, jak w celu uzyskania tokena dostępu i użycia go do uzyskania dostępu do bezpiecznego interfejsu API.

Użycie tokena dostępu w celu uzyskania dostępu do chronionego zasób

Ponieważ Weatherapi jest zabezpieczony protokołem OAuth 2.0, aplikacje muszą przedstawiać tokeny dostępu do wykorzystania interfejs API. Aby uzyskać dostęp do chronionego zasobu, aplikacja przedstawia w żądaniu token dostępu jako „Autoryzacja” nagłówek HTTP w taki sposób:

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

Ponieważ do interfejsu API jest dołączona zasada OAuthV2, Apigee Edge sprawdzi, czy token dostępu przedstawiana jest prawidłowa wartość, a następnie przyznaje dostęp do interfejsu API, zwracając aplikację pogodową który przesłał prośbę.

W jaki sposób aplikacje uzyskują tokeny dostępu? Omówimy to w następnej sekcji.

Jak wymienić dane logowania klienta na token dostępu

Aplikacje uzyskują tokeny dostępu, przedstawiając swoje pary klucza klienta/tajnego klucza tokenowi . Punkt końcowy tokena jest skonfigurowany na serwerze proxy interfejsu API o nazwie oauth. Aplikacje muszą wywoływać interfejs API udostępniany przez interfejs API oauth. serwera proxy, aby uzyskać token dostępu. Gdy aplikacja otrzyma token dostępu, będzie mogła wywoływać metodę Weatherapi aż do wygaśnięcia tokena dostępu lub jego unieważnienia.

Musisz teraz myśleć o sobie jak o deweloperam aplikacji. Chcesz, aby nazwa Weatherapi, więc musisz uzyskać token dostępu do swojej aplikacji. Najpierw musisz uzyskaj parę klucza i tajnego klucza klienta (znanej też jako interfejs API lub klucz aplikacji).

Klucz klienta i tajny klucz klienta możesz uzyskać, rejestrując aplikację w organizacji w Apigee Edge.

Możesz zobaczyć wszystkie aplikacje w organizacji w interfejsie zarządzania Apigee Edge.

Pojawi się lista aplikacji zarejestrowanych w Twojej organizacji.

Jeśli nie wyświetlają się żadne aplikacje, więcej informacji o rejestrowaniu aplikacji znajdziesz w temacie Zarejestruj aplikacje i zarządzaj interfejsem API ).

Wybierz aplikację z listy, aby wyświetlić jej szczegółowy profil.

W widoku szczegółów wybranej aplikacji zwróć uwagę na pola Klucz klienta. i Consumer Secret (Tajny klucz klienta). Te dwie wartości to parametr client danych uwierzytelniających, których będziesz używać do uzyskania tokena dostępu OAuth.

$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps \
-u myname:mypass 

Wywołanie zwraca listę aplikacji posortowaną według identyfikatora aplikacji.

[ "da496fae-2a04-4a5c-b2d0-709278a6f9db", "50e3e831-175b-4a05-8fb6-05a54701af6e" ]

Aby pobrać profil aplikacji, wykonaj proste wywołanie GET dla identyfikatora aplikacji:

$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/{app_id} \
-u myname:mypass 

Na przykład:

$ curl https://api.enterprise.apigee.com/v1/o/{org_name}/apps/da496fae-2a04-4a5c-b2d0-709278a6f9db \
-u myname:mypass 

Wywołanie interfejsu API zwraca profil określonej aplikacji. Na przykład profil aplikacji Element Weatherapp ma taką reprezentację w formacie JSON:

{
  "accessType" : "read",
  "apiProducts" : [ ],
  "appFamily" : "default",
  "appId" : "da496fae-2a04-4a5c-b2d0-709278a6f9db",
  "attributes" : [ ],
  "callbackUrl" : "http://weatherapp.com",
  "createdAt" : 1380290158713,
  "createdBy" : "noreply_admin@apigee.com",
  "credentials" : [ {
    "apiProducts" : [ {
      "apiproduct" : "PremiumWeatherAPI",
      "status" : "approved"
    } ],
    "attributes" : [ ],
    "consumerKey" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
    "consumerSecret" : "hAr4Gn0gA9vAyvI4",
    "expiresAt" : -1,
    "issuedAt" : 1380290161417,
    "scopes" : [ ],
    "status" : "approved"
  } ],
  "developerId" : "5w95xGkpnjzJDBT4",
  "lastModifiedAt" : 1380290158713,
  "lastModifiedBy" : "noreply_admin@apigee.com",
  "name" : "weatherapp",
  "scopes" : [ ],
  "status" : "approved"
}

Zwróć uwagę na wartości consumerKey i consumerSecret. Używasz tych funkcji danych logowania, aby uzyskać token dostępu, prezentując je jako dane uwierzytelniające żądanie HTTP, jak pokazano poniżej. Typ uwierzytelnienia jest prezentowany w żądaniu jako parametr zapytania. (Pamiętaj, aby zmienić wartość zmiennej {org_name} tak, aby odzwierciedlała nazwę Twojej organizacji w Apigee Edge).

Utwórz prośbę o uzyskanie tokena dostępu

W poniższym żądaniu zastąp wartość pola consumerKey wartością client_id Zastąp wartość powiązanego elementu consumerSecret przez client_secret

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

Usługi API sprawdzają klucz i tajny klucz klienta, a następnie generują odpowiedź zawierającą token dostępu dla tej aplikacji:

{
  "issued_at" : "1380892555397",
  "application_name" : "957aa73f-25c2-4ead-8021-adc01f0d2c6b",
  "scope" : "",
  "status" : "approved",
  "api_product_list" : "[oauth-test]",
  "expires_in" : "3599",
  "developer.email" : "tesla@weathersample.com",
  "organization_id" : "0",
  "client_id" : "bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K",
  "access_token" : "ylSkZIjbdWybfs4fUQe9BqP0LH5Z",
  "organization_name" : "rqa",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

Zwróć uwagę na wartość access_token w powyższej odpowiedzi. To jest token dostępu, który będzie używana w celu uzyskania dostępu w czasie działania do chronionych zasobów. Token dostępu tej aplikacji to ylSkZIjbdWybfs4fUQe9BqP0LH5Z

Masz teraz prawidłowy token dostępu (ylSkZIjbdWybfs4fUQe9BqP0LH5Z), którego można użyć aby uzyskać dostęp do chronionych interfejsów API.

Praca z domyślną konfiguracją OAuth

Każda organizacja (nawet organizacja w ramach bezpłatnego okresu próbnego) w Apigee Edge ma dostęp do tokena OAuth punktu końcowego. Punkt końcowy jest wstępnie skonfigurowany za pomocą zasad na serwerze proxy interfejsu API wywoływanym oauth. Z punktu końcowego tokena możesz zacząć korzystać od razu po utworzeniu konta w Apigee Edge.

Domyślny punkt końcowy OAuth udostępnia ten identyfikator URI punktu końcowego:

/oauth/client_credential/accesstoken

Opublikuj ten identyfikator URI dla deweloperów, którzy chcą uzyskać tokeny dostępu. Konfiguracja przez deweloperów aplikacji aplikacji do wywoływania tego punktu końcowego i przedstawiania pary klucza klienta i hasła w celu uzyskania dostępu tokeny.

Domyślny punkt końcowy tokena danych logowania klienta jest dostępny w sieci w: Adres URL:

https://{org_name}-{env_name}.apigee.net/oauth/client_credential/accesstoken

Jeśli na przykład nazwa organizacji to „apimakers”, adres URL będzie wyglądać tak:

https://apimakers-test.apigee.net/oauth/client_credential/accesstoken

Jest to adres URL, który deweloperzy wywołują w celu uzyskania tokenów dostępu.

Konfiguracje trzyetapowej autoryzacji OAuth

Konfiguracje trzyetapowej autoryzacji OAuth (kod autoryzacji, niejawne uwierzytelnienie i uwierzytelnienie z użyciem hasła ) wymaga od Ciebie, jako dostawcy interfejsu API, uwierzytelniania użytkowników aplikacji. Od organizacja uwierzytelnia użytkowników na różne sposoby, wymagane jest dostosowanie zasad lub wprowadzenie kodu do zintegrowania protokołu OAuth z magazynem użytkowników. Na przykład wszyscy użytkownicy mogą być zapisani w folderze Aktywne. Katalogu, LDAP lub innym magazynie użytkowników. Aby skonfigurować trzyetapową autoryzację OAuth, musisz zintegrować kontrolę tego magazynu użytkowników z ogólnym procesem OAuth.

OAuth 1.0a

Więcej informacji o zasadach dotyczących protokołu OAuth 1.0a znajdziesz w artykule Zasady dotyczące protokołu OAuth 1.0a.

Pomoc

Więcej informacji znajdziesz na stronie Apigee Obsługa Klienta.