Przeglądasz dokumentację Apigee Edge.
Przejdź do
Dokumentacja Apigee X. informacje.
Strona główna protokołu OAuth: Na stronie głównej OAuth znajdziesz ogólny widok wskazówek dotyczących protokołu OAuth, które udostępniać.
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 stron poświęconych protokołu OAuth 2.0. Zdecydowanie zalecamy zacznij od sprawdzenia protokołu IETF OAuth 2.0 specyfikacji. Oto definicja protokołu OAuth 2.0 ze specyfikacji IETF protokołu OAuth 2.0 :
„Platforma autoryzacji OAuth 2.0 umożliwia uzyskania ograniczonego dostępu do usługi HTTP, w imieniu właściciela zasobu przez administruje interakcją dotyczącą zatwierdzania między właścicielem zasobu a usługą HTTP lub umożliwiając aplikacji zewnętrznej uzyskanie dostępu we własnym imieniu”.
Przede wszystkim musisz wiedzieć, że OAuth 2.0 umożliwia aplikacjom ograniczony dostęp do chronionych zasobów użytkownika (takich jak konto bankowe lub inne informacji poufnych, do których użytkownik mógłby chcieć uzyskać dostęp w aplikacji) bez konieczności ujawnić aplikacji swoje dane logowania.
Proces OAuth 2.0
Poniżej znajdziesz ogólny opis przepływu pracy platformy zabezpieczeń OAuth 2.0. Omówimy ten proces bardziej szczegółowo w tym artykule, zaczynając od diagramu, który dobrze ilustruje działanie protokołu OAuth 2.0. Jeśli nie znasz terminów użytych na tym diagramie, w ramach krótkiej sekcji zapoznaj się z tą sekcją
Terminy, które warto znać
- Klient: zwany również „aplikacją”. Może to być aplikacja działająca na komórce, na urządzeniach mobilnych lub w tradycyjnej aplikacji internetowej. Aplikacja wysyła żądania do serwera zasobów w przypadku zasobów chronionych w imieniu właściciela zasobu. Właściciel zasobu musi przyznać aplikacji uprawnienia aby uzyskać dostęp do zabezpieczonych zasobów.
- Właściciel zasobu: nazywany też „użytkownikiem końcowym”. Jest to zwykle osoba (lub inny podmiot), która może przyznać dostęp do chronionego zasobu. Dla: Jeśli na przykład aplikacja musi używać danych z jednej z Twoich witryn mediów społecznościowych, właściciel zasobu – jedyna osoba, która może przyznać aplikacji dostęp do Twoich danych.
- Serwer zasobów:traktuj serwer zasobów jak usługę Facebook, Google lub Twitter; lub usługi HR w intranecie; lub z usługą partnerską Ekstranet B2B. Apigee Edge jest serwerem zasobów, gdy wymagana jest weryfikacja tokena OAuth do przetwarzania żądań do interfejsu API. Serwer zasobów wymaga autoryzacji przed rozpoczęciem obsługi na dostęp do zabezpieczonych zasobów.
- Serwer autoryzacji: zaimplementowany jest serwer autoryzacji. zgodnie ze specyfikacją OAuth 2.0 i odpowiada za sprawdzaniu przyznanych autoryzacji i udzielania dostępu tokeny , które dają aplikacji dostęp do danych użytkownika na serwerze zasobów. Ty może konfigurować „punkty końcowe tokena” w Apigee Edge, w którym to Edge przyjmuje rolę serwera autoryzacji.
- Przyznanie autoryzacji: przyznaje aplikacji uprawnienia do pobierania dostępu. OAuth 2.0 definiuje 4 określone „typy uwierzytelnień”. Zapoznaj się z sekcją „Jakie są typy uwierzytelnienia OAuth 2.0”. poniżej.
- Token dostępu: długi ciąg znaków służący jako dane logowania. używane do uzyskiwania dostępu do zabezpieczonych zasobów. Więcej informacji znajdziesz w artykule „Co to jest dostęp token? poniżej.
- Chroniony zasób: dane należące do właściciela zasobu. Na przykład parametr listy kontaktów użytkownika, informacji o koncie lub innych danych wrażliwych.
Miejsce, w którym mieści się Apigee Edge
Możesz chronić każdy interfejs API przesyłany przez serwer proxy przez Apigee Edge przy użyciu protokołu OAuth 2.0. Edge zawiera i weryfikacja serwera autoryzacji, co pozwala generować i weryfikować tokeny dostępu. Deweloperzy zaczynają od zarejestrowania swoich aplikacji w Apigee Edge. Zarejestrowane aplikacje mogą prosić o tokeny dostępu w ramach dowolnego z 4 przyznanych aplikacji typ interakcji.
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. Dla: można 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 dane logowania są prawidłowe.
Pamiętaj, że wszystkie serwery zasobów, które wywołuje bezpieczny serwer proxy interfejsu API, powinny znajdować się za zaporą sieciową (oznacza to, że zasoby nie mogą być dostępne w żaden sposób poza serwerem proxy API lub innymi i dobrze zabezpieczony interfejs API).
Co to jest OAuth 2.0 typy uwierzytelnień?
Rodzaje grantów to różne ścieżki lub interakcje, jakie aplikacja może wykonać, aby uzyskać dostęp. token. Każdy typ uwierzytelnienia odnosi się do co najmniej 1 przypadku użycia. Musisz wybrać, który w zależności od potrzeb. Ogólnie każdy rodzaj uwierzytelnienia ma zalety i i wyliczaj wady oraz należy rozważyć oszczędności na podstawie przypadków użycia w firmie. Jedna należy wziąć pod uwagę „wiarygodność”, które mają mieć dostęp do Twoich danych. Zasadniczo aplikacje innych firm są mniej godne zaufania niż aplikacje tworzone i używane firmy.
Apigee Edge obsługuje 4 główne typy uwierzytelnień OAuth 2.0:
- kod autoryzacji – uważany za najbezpieczniejszy typ uwierzytelnienia. Przed serwer autoryzacji wydaje token dostępu, aplikacja musi najpierw otrzymać kod autoryzacji z serwera zasobów. Ten proces pojawia się za każdym razem, gdy Twoja aplikacja otworzy stronę stronie logowania na serwer zasobów i z zaproszeniem do zalogowania się na właściwe konto (np. Facebook czy Twitter).
Jeśli się zalogujesz, aplikacja otrzyma autoryzację. za pomocą którego może negocjować token dostępu z serwerem autoryzacji. Zwykle jest używany, gdy aplikacja znajduje się na serwerze, a nie na kliencie. Ten typ uwierzytelnienia to uważane za bardzo bezpieczne, ponieważ aplikacja kliencka nie obsługuje ani nie widzi nazwy użytkownika ani hasła do serwera zasobów (tzn. aplikacja nigdy nie widzi ani nie obsługuje Twojego dane logowania do Twittera). Ten przepływ typu uwierzytelnienia jest też nazywany „trzyetapowym”. OAuth.
- implicit – uważane za uproszczoną wersję kodu autoryzacji. Ten typ uwierzytelnienia jest zwykle używany, gdy aplikacja znajduje się w kliencie. Na przykład adres URL aplikacji został wdrożony w przeglądarce za pomocą JavaScriptu lub innego języka skryptowego (zamiast w której działa i który jest uruchomiony na oddzielnym serwerze WWW). W tym przepływie typu uwierzytelnienia Gdy użytkownik jest uwierzytelniony, serwer zwraca token dostępu bezpośrednio, zamiast kod autoryzacji. W niektórych przypadkach przyznania pośrednie mogą poprawić czas reagowania aplikacji, ale tę przewagę należy wziąć pod uwagę, biorąc pod uwagę potencjalne zagrożenia dla bezpieczeństwa, zgodnie z Specyfikacja IETF.
- Dane logowania właściciela zasobu – w tym procesie klient wystawiany jest 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 może być uwierzytelnianie podstawowe jest takie, że użytkownik podaje nazwę użytkownika i hasło tylko raz. Od tego momentu włączony jest token dostępu.
- danych logowania klienta – warto je stosować w sytuacjach, gdy klient aplikacja działa we własnym imieniu. Oznacza to, że klient jest też właścicielem zasobu. To uwierzytelnienie jest zwykle używany, gdy aplikacja potrzebuje dostępu do usługi przechowywania danych w backendzie, przykład. Aplikacja musi używać usługi do swoich zadań, przez co usługa jest nieprzezroczysta. do użytkownika. W przypadku tego typu uwierzytelnienia aplikacja może otrzymać token dostępu, prezentując identyfikatora klienta i klucza tajnego klienta do serwera autoryzacji. Nie musisz robić nic więcej. Edge zapewnia gotowe rozwiązanie do obsługi danych logowania klienta, które jest łatwe do wdrożenia dla każdego Proxy API.
Co to jest dostęp token?
Token dostępu to długi ciąg znaków służący jako dane logowania używane do uzyskiwania dostępu do zasobów chronionych. Tokeny zasobów (nazywane też tokenami okaziciela) są przekazywane w autoryzacji takie jak:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Serwer zasobów rozumie, że token dostępu jest „zastępowany”. dla danych logowania, takich jak nazwa użytkownika i hasło. Dodatkowo tokeny dostępu mogą być wydawane z ograniczeniami, dzięki czemu: na przykład aplikacja może odczytywać dane na serwerze zasobów, ale nie może ich zapisywać. Pamiętaj, że token dostępu może zostać unieważniony, jeśli na przykład aplikacja zostanie przejęta. W takim przypadku musisz podać aby uzyskać nowy token dostępu i dalej korzystać z aplikacji; jednak nie musisz zmieniać nazwa użytkownika lub hasło na serwerze chronionych zasobów (np. Facebook czy Twitter).
Tokeny dostępu zwykle mają datę ważności (ze względów bezpieczeństwa). Niektóre typy uwierzytelnienia zezwalają serwera autoryzacji do wystawienia tokena odświeżania, który pozwala aplikacji pobrać nowy token dostępu gdy stary kod wygaśnie. Więcej informacji o tokenach dostępu i odświeżania znajdziesz w dokumentacji protokołu OAuth IETF Specyfikacja 2.0.
Ograniczony dostęp przez zakresy
Za pomocą zakresu zakresów OAuth 2.0 może przyznać aplikacji ograniczony dostęp do chronionych i zasobami Google Cloud. Na przykład aplikacja może mieć dostęp tylko do określonych zasobów, może być w stanie aktualizować zasobów lub może mieć dostęp tylko do odczytu. pod tzw. „trójnożną”, przepływy OAuth, użytkownik zwykle określa poziom dostępu za pomocą strony z prośbą o zgodę na przetwarzanie danych (np. w którym użytkownik wybiera zakres za pomocą pola wyboru innego mechanizmu).
Rejestrowanie aplikacji
Wszystkie klienty (aplikacje) muszą być zarejestrowane na serwerze autoryzacji OAuth 2.0, z którego korzystają ma zamiar żądać tokenów dostępu. Po zarejestrowaniu aplikacji otrzymasz z powrotem zestaw kluczy. Jeden to klucz publiczny nazywany identyfikatorem klienta, a drugi to tajny klucz klienta. obiektu tajnego. Bez tych kluczy aplikacja nie może wysyłać żądań kodów autoryzacji ani tokenów dostępu do serwera autoryzacji. Pamiętaj, że specyfikacja protokołu OAuth IETF wywołuje tych klientów kluczy identyfikator i tajny klucz klienta, interfejs Apigee Edge wywołuje te identyfikatory: identyfikator klienta i tajny klucz klienta. Są odpowiednik.
Podsumowanie przypadków użycia protokołu OAuth 2.0
To, który typ uwierzytelnienia OAuth 2.0 wybierzesz, zależy od konkretnego przypadku użycia: niektóre typy uwierzytelnienia są bezpieczniejsze niż inne. Wybór typu uwierzytelnienia zależy od wiarygodności aplikacji klienckiej i wymaga bardzo starannego sprawdzenia, tak jak to opisano w ta tabela:
| Przypadek użycia | Wiarygodność | Sugerowane typy autoryzacji OAuth 2.0 | Opis |
|---|---|---|---|
| B2B (ekstranet), intranet, inne |
aplikacje o wysokim stopniu zaufania, napisane przez wewnętrznego dewelopera lub zaufaną osobę; relacje biznesowe z dostawcą interfejsu API. Aplikacje, które muszą uzyskiwać dostęp do zasobów w swoim imieniu. |
|
|
| Witryny intranetowe i portale |
Zaufane aplikacje napisane przez wewnętrznych lub zaufanych deweloperów zewnętrznych. Dobrym przykładem jest zalogowanie się na stronie działu kadr firmy w celu wyboru ubezpieczenia, przesyłać opinii ani zmieniać danych osobowych. |
|
|
| Aplikacje dostępne publicznie | Niezaufane aplikacje zostały napisane przez zewnętrznych deweloperów, którzy nie współpracują z zaufanymi firmami. z dostawcą interfejsu API. Na przykład deweloperzy, którzy zarejestrowali się w celu korzystania z publicznych interfejsów API programy nie powinny być ogólnie zaufane. |
|
|
| Segment B2C | Dotyczy pojedynczego użytkownika (użytkownika urządzeń mobilnych), a dane logowania użytkownika są przechowywane na urządzeniu mobilnym. |
|
|
Interfejs OAuth 2.0 a klucz interfejsu API zabezpieczenia
Weryfikacja klucza interfejsu API wymaga, aby aplikacja wysyłała klucz do Edge. Klucz musi być prawidłowym kluczem klienta z aplikacji dla deweloperów Apigee Edge powiązanej z serwerem proxy interfejsu API. Jeśli z jakiegoś powodu musisz unieważnić uprawnienia aplikacji klienckiej na nawiązywanie połączeń z serwerem proxy, musisz je unieważnić klucz klienta. Żadna aplikacja kliencka, która używa tego klucza, również nie będzie miała dostępu do serwera proxy interfejsu API. Dzień token OAuth można unieważnić w dowolnym momencie bez unieważniania kluczy aplikacji. Aplikacja po prostu poprosić o nowy token w imieniu użytkownika. Jeśli go przyzna, aplikacja nadal używaj serwera proxy interfejsu API.
Kolejną różnicą między kluczem interfejsu API a tokenem jest to, że token może zawierać metadane które można pobrać i wykorzystać później. Możesz na przykład przechowywać identyfikator użytkownika przez wywołanie interfejsu API i używanie go do dostosowywania wywołań usługi docelowej backendu.
Szczegółowe informacje o weryfikacji klucza interfejsu API znajdziesz w sekcji Interfejs API . Informacje o korzystaniu z atrybutów niestandardowych z tokenami OAuth znajdziesz w sekcji Dostosowywanie tokenów Authorization Codes (Kody autoryzacji).
Zalecane zasoby
Czytanie
Zapoznaj się z informacjami o OAuth 2.0.