Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Strona główna protokołu OAuth: otwórz stronę główną protokołu OAuth, aby uzyskać ogólny widok przygotowanych przez nas wskazówek dotyczących protokołu OAuth.
Ten temat zawiera podstawowe omówienie protokołu OAuth 2.0 w Apigee Edge.
Co to jest OAuth 2.0?
Istnieje wiele książek, blogów i witryn poświęconych OAuth 2.0. Zdecydowanie zalecamy rozpoczęcie od zapoznania się ze specyfikacją protokołu OAuth 2.0 IETF. Oto definicja protokołu OAuth 2.0 podana w specyfikacji IETF OAuth 2.0:
„Platforma autoryzacji OAuth 2.0 umożliwia aplikacji zewnętrznej uzyskanie ograniczonego dostępu do usługi HTTP w imieniu właściciela zasobu przez zarządzanie interakcją dotyczącą zatwierdzania między właścicielem zasobu a usługą HTTP lub przez umożliwienie aplikacji zewnętrznej uzyskania dostępu w swoim imieniu”.
Najważniejszą rzeczą, o której musisz wiedzieć, jest to, że protokół OAuth 2.0 umożliwia aplikacjom uzyskanie ograniczonego dostępu do zabezpieczonych zasobów użytkownika (dotyczy to konta bankowego i innych informacji poufnych, do których użytkownik może chcieć uzyskać dostęp z aplikacji) bez konieczności ujawniania swoich danych logowania.
Proces OAuth 2.0
Poniżej znajdziesz ogólny przepływ informacji o platformie zabezpieczeń OAuth 2.0. Omówimy ten proces bardziej szczegółowo w tym temacie, zaczynając od diagramu, który dokładnie ilustruje działanie protokołu OAuth 2.0. Jeśli nie znasz terminów użytych na tym diagramie, przeczytaj tę sekcję, aby szybko się z nimi zapoznać.
Terminy, które warto znać
- Klient: inaczej „aplikacja”. Może to być aplikacja działająca na urządzeniu mobilnym lub tradycyjną aplikację internetową. Aplikacja wysyła w imieniu właściciela żądania do serwera zasobów żądania chronionych zasobów. Właściciel zasobu musi przyznać aplikacji uprawnienia dostępu do zabezpieczonych zasobów.
- Właściciel zasobu – inaczej „użytkownik końcowy”. Jest to zwykle osoba (lub inny podmiot), która może przyznać dostęp do chronionego zasobu. Jeśli na przykład aplikacja musi używać danych z jednego z Twoich serwisów społecznościowych, jesteś właścicielem zasobu – jedyną osobą, która może przyznać aplikacji dostęp do tych danych.
- Serwer zasobów: możesz myśleć o serwerze zasobów jak o usłudze Facebook, Google czy Twitter, o usłudze kadr w intranecie czy o usłudze partnerskiej w ekstranecie B2B. Apigee Edge jest serwerem zasobów, gdy do przetwarzania żądań do interfejsu API wymagana jest weryfikacja tokena OAuth. Serwer zasobów wymaga pewnej autoryzacji, zanim będzie udostępniać w aplikacji chronione zasoby.
- Serwer autoryzacji: serwer autoryzacji został wdrożony zgodnie ze specyfikacją OAuth 2.0 i odpowiada za weryfikowanie przyznań autoryzacji oraz wystawianie tokenów dostępu, które przyznają aplikacji dostęp do danych użytkownika na serwerze zasobów. Możesz skonfigurować „punkty końcowe tokena” w Apigee Edge, wtedy Edge przejmie rolę serwera autoryzacji.
- Przyznanie autoryzacji: daje aplikacji uprawnienia do pobierania tokena dostępu w imieniu użytkownika. OAuth 2.0 definiuje 4 określone „typy uwierzytelnienia”. Zapoznaj się poniżej z sekcją „Jakie są typy uwierzytelniania OAuth 2.0”.
- Token dostępu: długi ciąg znaków służący jako dane logowania umożliwiające dostęp do chronionych zasobów. Więcej informacji znajdziesz poniżej w sekcji „Co to jest token dostępu?”.
- Chroniony zasób: dane należące do właściciela zasobu. Mogą to być na przykład lista kontaktów użytkownika, informacje o koncie lub inne dane wrażliwe.
Gdzie pasuje Apigee Edge
Korzystając z protokołu OAuth 2.0, możesz chronić wszystkie interfejsy API korzystające z serwera proxy przez Apigee Edge. Edge zawiera implementację serwera autoryzacji, dzięki czemu może generować i weryfikować tokeny dostępu. Deweloperzy zaczynają od zarejestrowania aplikacji w Apigee Edge. Zarejestrowane aplikacje mogą prosić o tokeny dostępu za pomocą dowolnej z 4 interakcji typu przyznania.
Apigee udostępnia wieloaspektowe zasady OAuthV2, które implementują szczegóły każdego typu uwierzytelnienia, co ułatwia skonfigurowanie protokołu OAuth w Apigee Edge. Możesz na przykład skonfigurować zasadę, która odbiera żądanie tokena dostępu, ocenia wszystkie wymagane dane uwierzytelniające i zwraca token dostępu, jeśli są one prawidłowe.
Wszystkie serwery zasobów, które wywołują bezpieczny serwer proxy interfejsu API, powinny znajdować się za zaporą sieciową (tzn. zasoby nie mogą być dostępne inaczej niż przez serwer proxy interfejsu API lub inny, dobrze zabezpieczony interfejs API).
Czym są typy uwierzytelnienia OAuth 2.0?
Typy uwierzytelniania to różne ścieżki lub interakcje, które aplikacja może podjąć, aby uzyskać token dostępu. Każdy typ uwierzytelnienia dotyczy co najmniej 1 przypadku użycia. Musisz wybrać typy przyznania, których chcesz użyć, kierując się własnymi potrzebami. Ogólnie rzecz biorąc, każdy rodzaj grantu ma swoje zalety i wady, dlatego należy rozważyć kompromisy w zależności od przypadków użycia w danym regionie. Jedną z ważniejszych kwestii jest „wiarygodność” aplikacji, które będą miały dostęp do Twoich danych. Ogólnie aplikacje innych firm są mniej wiarygodne niż aplikacje opracowane i używane w firmie.
Apigee Edge obsługuje 4 główne typy uwierzytelniania OAuth 2.0:
- kod autoryzacji – jest uważany za najbezpieczniejszy typ uwierzytelnienia. Zanim serwer autoryzacji wygeneruje token dostępu, aplikacja musi najpierw otrzymać kod autoryzacji z serwera zasobów. Widzisz taki przepływ za każdym razem, gdy Twoja aplikacja otwiera przeglądarkę i wyświetla stronę logowania serwera zasobów i zaprasza Cię do zalogowania się na swoje własne konto (na przykład Facebooka lub Twittera).
Jeśli się zalogujesz, aplikacja otrzyma kod autoryzacji, za pomocą którego może negocjować token dostępu z serwerem autoryzacji. Ten typ uwierzytelnienia jest zwykle używany, gdy aplikacja znajduje się na serwerze, a nie po stronie klienta. Ten typ uwierzytelnienia jest uważany za bardzo bezpieczny, ponieważ aplikacja kliencka nigdy nie obsługuje ani nie widzi nazwy użytkownika i hasła użytkownika na serwerze zasobów (oznacza to, że aplikacja nigdy nie widzi ani nie obsługuje Twoich danych logowania do Twittera). Ten przepływ typu uwierzytelnienia jest też nazywany „trzyetapową” uwierzytelnianiem OAuth.
- implicit – jest uznawany za uproszczoną wersję kodu autoryzacji. Ten typ uwierzytelnienia jest zwykle używany, gdy aplikacja znajduje się na kliencie. Na przykład kod aplikacji jest zaimplementowany w przeglądarce przy użyciu JavaScriptu lub innego języka skryptowego (a nie umieszczony i uruchamiany na osobnym serwerze WWW). W tym procesie uwierzytelniania serwer autoryzacji zwraca token dostępu bezpośrednio, gdy użytkownik jest uwierzytelniony, zamiast wystawiać kod autoryzacji. Przyznania niejawne mogą w niektórych przypadkach poprawić responsywność aplikacji, ale tę zaletę należy wziąć pod uwagę w kontekście możliwych zagrożeń dla bezpieczeństwa, jak opisano w specyfikacji IETF.
- Dane uwierzytelniające z hasłem właściciela zasobu – w ramach tego procesu klient otrzymuje token dostępu, gdy nazwa użytkownika i hasło zostaną zweryfikowane przez serwer autoryzacji. Ten proces jest zalecany w przypadku aplikacji o wysokim stopniu zaufania. Zaletą tego procesu jest na przykład to, że użytkownik przedstawi swoją nazwę użytkownika i hasło tylko raz. Od tego momentu używany jest token dostępu.
- danych logowania klienta – rozważ użycie w sytuacjach, gdy aplikacja kliencka działa we własnym imieniu. Oznacza to, że klient jest też właścicielem zasobu. Ten typ uwierzytelnienia jest zwykle używany, gdy aplikacja potrzebuje dostępu do usługi backendu danych. Aplikacja musi korzystać z usługi do wykonywania swoich zadań, a poza tym usługa jest nieprzejrzysta dla użytkownika. Dzięki temu typowi uwierzytelnienia aplikacja może otrzymać token dostępu, prezentując swój identyfikator klienta i klucze tajnego klienta na serwerze autoryzacji. Nie musisz robić nic więcej. Edge udostępnia gotowe rozwiązanie do obsługi danych logowania klienta, które można łatwo wdrożyć na dowolnym serwerze proxy interfejsu API.
Co to jest token dostępu?
Token dostępu to długi ciąg znaków, który służy jako dane uwierzytelniające umożliwiające dostęp do chronionych zasobów. Tokeny zasobów (nazywane też tokenami okaziciela) są przekazywane w nagłówkach autoryzacji:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Serwer zasobów rozumie, że token dostępu jest ważny dla danych logowania, takich jak nazwa użytkownika i hasło. Dodatkowo tokeny dostępu mogą być wydawane z ograniczeniami, więc na przykład aplikacja może odczytywać dane na serwerze zasobów, ale nie może ich zapisywać ani usuwać. Pamiętaj, że token dostępu może zostać unieważniony, jeśli na przykład aplikacja zostanie przejęta. W takim przypadku, aby nadal korzystać z aplikacji, musisz uzyskać nowy token dostępu. Nie musisz jednak zmieniać nazwy użytkownika ani hasła na serwerze chronionych zasobów (takich jak Facebook czy Twitter).
Tokeny dostępu zazwyczaj mają datę ważności (ze względów bezpieczeństwa). Niektóre typy uwierzytelniania pozwalają serwerowi autoryzacji wygenerować token odświeżania, dzięki któremu aplikacja może pobrać nowy token dostępu, gdy stary token wygaśnie. Więcej informacji o tokenach dostępu i odświeżaniu znajdziesz w specyfikacji protokołu OAuth 2.0 IETF.
Ograniczony dostęp przez zakresy
Za pomocą mechanizmów zakresów protokół OAuth 2.0 może przyznać aplikacji ograniczony dostęp do chronionych zasobów. Na przykład aplikacja może mieć dostęp tylko do określonych zasobów, może aktualizować zasoby lub może mieć dostęp tylko do odczytu. W ramach tzw. „trzyetapowych” procesów OAuth użytkownik zwykle określa poziom dostępu na stronie wyrażania zgody (na przykład na stronie internetowej, na której użytkownik wybiera zakres, zaznaczając pole wyboru obok innego mechanizmu).
Rejestrowanie aplikacji
Wszystkie klienty (aplikacje) muszą rejestrować się na serwerze autoryzacji OAuth 2.0, z którego chcą żądać tokenów dostępu. Gdy zarejestrujesz aplikację, otrzymasz z powrotem zestaw kluczy. Jeden to klucz publiczny nazywany identyfikatorem klienta, a drugi to tajny klucz nazywany tajnym kluczem klienta. Bez tych kluczy aplikacja nie może wysyłać żądań kodów autoryzacji ani tokenów dostępu do serwera autoryzacji. Pamiętaj, że chociaż specyfikacja OAuth IETF wywołuje identyfikator klienta i tajny klucz klienta, interfejs Apigee Edge wywołuje te klucze jako Identyfikator klienta i Tajny klucz klienta. Są równoważne.
Podsumowanie przypadków użycia protokołu OAuth 2.0
Wdrożony przepływ typu uwierzytelniania OAuth 2.0 zależy od konkretnego przypadku użycia, ponieważ niektóre z nich są bezpieczniejsze od innych. Wybór rodzajów przyznanych uprawnień zależy od wiarygodności aplikacji klienta i wymaga bardzo starannego sprawdzenia, jak opisano w tej tabeli:
| Przykład zastosowania | Wiarygodność | Sugerowane typy autoryzacji OAuth 2.0 | Opis |
|---|---|---|---|
| B2B (ekstranet), intranet, inne |
Aplikacje wysoce zaufane, napisane przez wewnętrznego dewelopera lub deweloperów mających zaufaną relację biznesową z dostawcą interfejsu API. Aplikacje, które potrzebują dostępu do zasobów we własnym imieniu. |
|
|
| Witryny intranetowe, portale |
Zaufane aplikacje napisane przez wewnętrznych lub zaufanych deweloperów zewnętrznych. Dobrym przykładem jest logowanie się w witrynie dla działów kadr w Twojej firmie, aby wybrać ubezpieczenie, przesłać opinię lub zmienić dane osobowe. |
|
|
| Aplikacje dostępne publicznie | Niezaufane aplikacje są pisane przez zewnętrznych deweloperów, którzy nie współpracują z dostawcą interfejsu API w sposób godny zaufania. Na przykład deweloperzy rejestrujący się w publicznych programach dotyczących interfejsów API nie powinni być ogólnie zaufani. |
|
|
| B2C | Bierze się pod uwagę indywidualny użytkownik (mobilny), a dane logowania użytkownika są przechowywane na urządzeniu mobilnym. |
|
|
Protokół OAuth 2.0 a klucz interfejsu API
Weryfikacja klucza interfejsu API wymaga od aplikacji wysłania klucza do Edge. Klucz musi być prawidłowym kluczem klienta z aplikacji programisty Apigee Edge powiązanej z serwerem proxy interfejsu API. Jeśli z jakiegoś powodu musisz anulować uprawnienia aplikacji klienckiej do nawiązywania połączeń z serwerem proxy, musisz unieważnić ten klucz klienta. Aplikacje klienckie używające tego klucza również nie będą miały dostępu do serwera proxy interfejsu API. Z drugiej strony token OAuth można unieważnić w dowolnym momencie bez unieważniania kluczy aplikacji. Aplikacja może po prostu poprosić o nowy token w imieniu użytkownika. Gdy ten token zostanie przyznany, może nadal korzystać z serwera proxy interfejsu API.
Inną różnicą między kluczem interfejsu API a tokenem jest to, że token może zawierać atrybuty metadanych, które możesz pobrać i użyć później. Możesz na przykład zapisać identyfikator użytkownika wywołującego interfejs API i użyć go do dostosowania wywołań docelowej usługi backendu.
Szczegółowe informacje o weryfikacji klucza interfejsu API znajdziesz w sekcji Klucze interfejsu API. Informacje o używaniu atrybutów niestandardowych z tokenami OAuth znajdziesz w artykule o dostosowywaniu tokenów i kodów autoryzacji.
Zalecane zasoby
Reading
Zobacz Informacje o OAuth 2.0.