Wprowadzenie do OAuth 2.0

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Strona główna OAuth: zobacz stronę główną OAuth, aby uzyskać ogólny wgląd w udostępniane przez nas wskazówki dotyczące OAuth .

W tym artykule znajdziesz podstawowe informacje o protokole OAuth 2.0 w Apigee Edge.

Co to jest OAuth 2.0?

Istnieje wiele książek, blogów i witryn poświęconych protokołowi OAuth 2.0. Zdecydowanie zalecamy rozpoczęcie od zapoznania się ze specyfikacją IETF OAuth 2.0. Oto definicja protokołu OAuth 2.0 z samej specyfikacji IETF OAuth 2.0:

„Struktura autoryzacji OAuth 2.0 umożliwia aplikacji innej firmy uzyskanie ograniczonego dostępu do usługi HTTP w imieniu właściciela zasobu przez skoordynowanie interakcji zatwierdzania między właścicielem zasobu a usługą HTTP lub przez umożliwienie aplikacji innej firmy uzyskania dostępu we własnym imieniu”.

Najważniejsze, co musisz wiedzieć, to że OAuth 2.0 umożliwia aplikacjom uzyskanie ograniczonego dostępu do chronionych zasobów użytkownika (np. konta bankowego lub innych poufnych informacji, do których użytkownik może chcieć uzyskać dostęp z aplikacji) bez konieczności ujawniania aplikacji danych logowania.

Przepływ OAuth 2.0

Oto ogólny przepływ struktury zabezpieczeń OAuth 2.0. Omówimy go bardziej szczegółowo w tym artykule. Zaczniemy od diagramu, który ilustruje wiele aspektów działania 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: nazywany też „aplikacją”. Może to być aplikacja działająca na urządzeniu mobilnym lub tradycyjna aplikacja internetowa. Aplikacja wysyła żądania do serwera zasobów dotyczące chronionych zasobów w imieniu właściciela zasobu. Właściciel zasobu musi przyznać aplikacji uprawnienia dostępu do chronionych zasobów.
• Właściciel zasobu: nazywany też „użytkownikiem końcowym”. Zwykle jest to 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 jednej z Twoich witryn mediów społecznościowych, to Ty jesteś właścicielem zasobu – jedyną osobą, która może przyznać aplikacji dostęp do Twoich danych.
• Serwer zasobów: serwer zasobów to usługa taka jak Facebook, Google czy Twitter; usługa HR w Twojej sieci intranet; usługa partnera w ekstranecie B2B. Apigee Edge jest serwerem zasobów, gdy do przetworzenia żądań interfejsu API wymagana jest weryfikacja tokena OAuth. Serwer zasobów potrzebuje jakiegoś rodzaju autoryzacji, zanim udostępni aplikacji chronione zasoby.
• Serwer autoryzacji: serwer autoryzacji jest zaimplementowany zgodnie ze specyfikacją OAuth 2.0 i odpowiada za weryfikację uwierzytelnień oraz wydawanie tokenów dostępu, które umożliwiają aplikacji dostęp do danych użytkownika na serwerze zasobów. W Apigee Edge możesz skonfigurować „punkty końcowe tokenów”. W takim przypadku Edge pełni rolę serwera autoryzacji.
• Uwierzytelnienie: umożliwia aplikacji pobranie tokena dostępu w imieniu użytkownika końcowego. OAuth 2.0 definiuje 4 konkretne „typy uwierzytelnień”. Więcej informacji znajdziesz w sekcji „Jakie są typy uwierzytelnień OAuth 2.0?” poniżej.
• Token dostępu: długi ciąg znaków, który służy jako dane logowania używane do uzyskiwania dostępu do chronionych zasobów. Więcej informacji znajdziesz w sekcji „Co to jest token dostępu?” poniżej.
• Chroniony zasób: dane należące do właściciela zasobu. Na przykład lista kontaktów użytkownika, informacje o koncie lub inne dane wrażliwe.

Rola Apigee Edge

Za pomocą protokołu OAuth 2.0 możesz chronić dowolny interfejs API, który jest obsługiwany przez serwer proxy w Apigee Edge. Edge zawiera implementację serwera autoryzacji , dzięki czemu może generować i weryfikować tokeny dostępu. Deweloperzy zaczynają od zarejestrowania swoich aplikacji w Apigee Edge. Zarejestrowane aplikacje mogą prosić o tokeny dostępu za pomocą dowolnej z 4 grant type interakcji typu uwierzytelnienia.

Apigee udostępnia wieloaspektową zasadę OAuthV2, która implementuje szczegóły każdego typu uwierzytelnienia, co ułatwia skonfigurowanie OAuth w Apigee Edge. Możesz na przykład skonfigurować zasadę, która odbiera żądanie tokena dostępu, sprawdza wszystkie wymagane dane logowania i zwraca token dostępu, jeśli dane logowania są prawidłowe.

Pamiętaj, że wszystkie serwery zasobów, do których wywołuje Twój bezpieczny serwer proxy interfejsu API, powinny znajdować się za zaporą (tzn. zasoby nie mogą być dostępne w żaden inny sposób niż przez serwer proxy interfejsu API lub inny dobrze zabezpieczony interfejs API).

Jakie są typy uwierzytelnień OAuth 2.0 ?

Typy uwierzytelnień to różne ścieżki lub interakcje, które aplikacja może wykorzystać, aby uzyskać token dostępu. Każdy typ uwierzytelnienia obejmuje co najmniej 1 przypadek użycia. Musisz wybrać typy uwierzytelnień, których chcesz używać, na podstawie własnych potrzeb. Ogólnie każdy typ uwierzytelnienia ma zalety i wady. Musisz rozważyć kompromisy na podstawie swoich przypadków użycia. Ważnym aspektem jest "wiarygodność" aplikacji, które będą uzyskiwać dostęp do Twoich danych. Aplikacje innych firm są zwykle mniej wiarygodne niż aplikacje opracowywane i używane w przedsiębiorstwie.

Apigee Edge obsługuje 4 główne typy uwierzytelnień OAuth 2.0:

• kod autoryzacji – uważany za najbezpieczniejszy typ uwierzytelnienia. Zanim serwer autoryzacji wyda token dostępu, aplikacja musi najpierw otrzymać kod autoryzacji z serwera zasobów. Ten przepływ jest widoczny, gdy aplikacja otwiera przeglądarkę na stronie logowania serwera zasobów i prosi o zalogowanie się na Twoje konto (np. Facebooka lub Twittera).

Jeśli zalogujesz się pomyślnie, aplikacja otrzyma kod autoryzacji , którego może użyć do negocjowania tokena dostępu z serwerem autoryzacji. Ten typ uwierzytelnienia jest zwykle używany, gdy aplikacja znajduje się na serwerze, a nie na kliencie. Ten typ uwierzytelnienia jest uważany za bardzo bezpieczny, ponieważ aplikacja kliencka nigdy nie obsługuje ani nie widzi nazwy użytkownika ani hasła użytkownika do serwera zasobów (np. aplikacja nigdy nie widzi ani nie obsługuje Twoich danych logowania do Twittera). Ten przepływ typu uwierzytelnienia jest też nazywany „trójskładnikowym” uwierzytelnianiem OAuth.

• niejawne – uważane 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 za pomocą JavaScript lub innego języka skryptowego (zamiast znajdować się i działać na osobnym serwerze WWW). W tym przepływie typu uwierzytelnienia serwer autoryzacji zwraca token dostępu bezpośrednio po uwierzytelnieniu użytkownika, zamiast najpierw wydawać kod autoryzacji. Uwierzytelnienia niejawne mogą w niektórych przypadkach zwiększyć szybkość reakcji aplikacji, ale tę zaletę należy rozważyć w kontekście możliwych implikacji związanych z bezpieczeństwem, zgodnie z opisem w specyfikacji IETF.
• dane logowania właściciela zasobu – w tym przepływie klient otrzymuje token dostępu, gdy serwer autoryzacji zweryfikuje nazwę użytkownika i hasło. Ten przepływ jest zalecany w przypadku aplikacji o wysokim poziomie zaufania. Zaletą tego przepływu w porównaniu np. z podstawowym uwierzytelnianiem jest to, że użytkownik podaje nazwę użytkownika i hasło tylko raz. Od tego momentu używany jest token dostępu.
• dane 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 musi uzyskać dostęp np. do usługi przechowywania danych w backendzie. Aplikacja musi używać usługi do wykonywania swojej pracy, a usługa jest niewidoczna dla użytkownika końcowego. W przypadku tego typu uwierzytelnienia aplikacja może otrzymać token dostępu, przekazując serwerowi autoryzacji identyfikator klienta i tajny klucz klienta. Nie są wymagane żadne dodatkowe czynności. Edge udostępnia gotowe rozwiązanie z danymi logowania klienta, które można łatwo zaimplementować w przypadku dowolnego serwera 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 logowania używane do uzyskiwania dostępu do chronionych zasobów. Tokeny zasobów (nazywane też tokenami okaziciela) są przekazywane w nagłówkach autoryzacji w ten sposób:

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

Serwer zasobów rozumie, że token dostępu „zastępuje” dane logowania, takie jak nazwa użytkownika i hasło. Ponadto tokeny dostępu mogą być wydawane z ograniczeniami, dzięki czemu, np. aplikacja może odczytywać, ale nie zapisywać ani nie usuwać danych na serwerze zasobów. Pamiętaj, że token dostępu może zostać unieważniony, jeśli np. aplikacja zostanie naruszona. 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 (np. Facebooka lub Twittera).

Tokeny dostępu zwykle mają termin ważności (ze względów bezpieczeństwa). Niektóre typy uwierzytelnień umożliwiają serwerowi autoryzacji wydanie tokena odświeżania, który pozwala aplikacji pobrać nowy token dostępu, gdy stary wygaśnie. Więcej informacji o tokenach dostępu i odświeżania znajdziesz w specyfikacji IETF OAuth 2.0.

Ograniczony dostęp przez zakresy

Dzięki mechanizmowi zakresów 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 mieć możliwość aktualizowania zasobów lub może mieć tylko dostęp do odczytu. W tzw. przepływach OAuth "trójskładnikowych", użytkownik zwykle określa poziom dostępu na stronie zgody (np. na stronie internetowej, na której użytkownik wybiera zakres za pomocą pola wyboru lub innego mechanizmu).

Rejestrowanie aplikacji

Wszyscy klienci (aplikacje) muszą zarejestrować się na serwerze autoryzacji OAuth 2.0, z którego zamierzają prosić o tokeny dostępu. Po zarejestrowaniu aplikacji otrzymasz zestaw kluczy. Jeden z nich to klucz publiczny nazywany identyfikatorem klienta, a drugi to klucz tajny nazywany tajnym kluczem klienta. Bez tych kluczy aplikacja nie może wysyłać do serwera autoryzacji żądań kodów autoryzacji ani tokenów dostępu. Pamiętaj, że w specyfikacji IETF OAuth te klucze są nazywane identyfikatorem klienta i tajnym kluczem klienta, a w interfejsie Apigee Edge – identyfikatorem konsumenta i tajnym kluczem konsumenta. Są one równoważne.

Podsumowanie przypadków użycia OAuth 2.0

Wybór przepływu typu uwierzytelnienia OAuth 2.0 zależy od konkretnego przypadku użycia, ponieważ niektóre typy uwierzytelnień są bezpieczniejsze od innych. Wybór typów uwierzytelnień zależy od wiarygodności aplikacji klienckiej i wymaga bardzo starannego rozważenia, jak opisano w tej tabeli:

Bezpieczeństwo OAuth 2.0 a klucza interfejsu API

Weryfikacja klucza interfejsu API wymaga, aby aplikacja wysłała klucz do Edge. Klucz musi być prawidłowym kluczem konsumenta z aplikacji dewelopera Apigee Edge, która jest powiązana z serwerem proxy interfejsu API. Jeśli z jakiegoś powodu musisz cofnąć uprawnienia aplikacji klienckiej do wywoływania serwera proxy, musisz unieważnić ten klucz konsumenta. Wszystkie aplikacje klienckie używające tego klucza również nie będą mogły uzyskać 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. Jeśli token zostanie przyznany, aplikacja może nadal korzystać z serwera proxy interfejsu API.

Kolejną różnicą między kluczem interfejsu API a tokenem jest to, że token może zawierać atrybuty metadanych , które możesz później pobrać i użyć. Możesz na przykład zapisać identyfikator użytkownika wywołującego interfejs API i użyć go do dostosowania wywołań usługi docelowej w backendzie.

Więcej informacji o weryfikacji klucza interfejsu API znajdziesz w artykule API klucze. Informacje o używaniu atrybutów niestandardowych z tokenami OAuth znajdziesz w artykule Dostosowywanie tokenów i kodów autoryzacji.

Polecane zasoby

Czytanie

Przeczytaj artykuł Informacje o protokole OAuth 2.0.