Przepływy OAuth 2.0 i typy tokenów

OAuth 2.0 definiuje cztery role. Właściciel zasobu to użytkownik, do którego należą dane, na przykład pliki na jego Dysku Google. Klient to aplikacja żądająca dostępu. Serwer autoryzacji wydaje tokeny dostępu, na przykład serwer OAuth firmy Google. Serwer zasobów przechowuje chronione dane, na przykład udostępnia je za pośrednictwem interfejsu API Dysku Google. Zrozumienie tych ról wyjaśnia cel każdego przepływu.

Przepływ kodu autoryzacji jest właściwym przepływem dla internetowych aplikacji działających po stronie serwera. Użytkownik uwierzytelnia się na serwerze autoryzacji, który przekierowuje go do klienta z krótkotrwałym kodem autoryzacyjnym. Serwer klienta wymienia ten kod na tokeny za pośrednictwem żądania w kanale back-channel. Tokeny nigdy nie przechodzą przez przeglądarkę, co chroni je przed wyciekiem do historii przeglądarki i nagłówka referrer.

Przepływ niejawny zaprojektowano z myślą o aplikacjach JavaScript działających wyłącznie w przeglądarce, które nie mogły bezpiecznie przechowywać sekretów klienta. Tokeny były zwracane bezpośrednio we fragmencie adresu URL, z pominięciem kanału back-channel. Przepływ niejawny został wycofany w OAuth 2.1, ponieważ PKCE (RFC 7636) umożliwia klientom publicznym bezpieczne korzystanie z przepływu kodu autoryzacji bez sekretu klienta.

Przepływ ROPC umożliwia klientom bezpośrednie pobieranie nazwy użytkownika i hasła użytkownika oraz wymianę tych danych na tokeny. Został przeznaczony dla wysoce zaufanych klientów pierwszej strony, ale zasadniczo niweczy cel OAuth, jakim jest uniemożliwienie aplikacjom dostępu do poświadczeń użytkowników. Został wycofany w OAuth 2.1 i nie należy go używać w żadnej nowej aplikacji.

Przepływ poświadczeń klienta służy do uwierzytelniania typu machine-to-machine (M2M), gdy żaden użytkownik nie bierze udziału w procesie. Klient uwierzytelnia się bezpośrednio na serwerze autoryzacji za pomocą identyfikatora klienta i jego sekretu, otrzymując token dostępu do własnego użytku. Typowe zastosowania to zadania działające w tle, komunikacja między mikrousługami oraz bramy API uzyskujące dostęp do usług zaplecza.

Przepływ autoryzacji urządzenia (RFC 8628) umożliwia korzystanie z OAuth na urządzeniach o ograniczonych możliwościach wprowadzania danych: inteligentnych telewizorach, konsolach do gier, drukarkach i urządzeniach IoT. Urządzenie wyświetla krótki kod i adres URL. Użytkownik odwiedza ten adres na telefonie lub komputerze, aby wyrazić zgodę. Urządzenie odpytuje serwer autoryzacji do momentu zakończenia autoryzacji przez użytkownika.

OAuth 2.0 definiuje dwa typy tokenów dostępu. Tokeny nieprzezroczyste to losowe ciągi znaków, które serwer zasobów weryfikuje, wywołując punkt końcowy introspekcji serwera autoryzacji. Tokeny dostępu JWT są samowystarczalne: serwer zasobów może weryfikować je lokalnie, sprawdzając podpis, co zmniejsza liczbę wywołań interfejsu API introspekcji, ale wymaga zarządzania kluczami.

Tokeny odświeżające to długotrwałe poświadczenia używane do uzyskiwania nowych tokenów dostępu po wygaśnięciu tokenu dostępu. Rotacja tokenów odświeżających, wymagana w OAuth 2.1 w przypadku klientów publicznych, polega na wydawaniu nowego tokenu odświeżającego przy każdym użyciu i unieważnianiu poprzedniego. Jeśli skradziony token odświeżający zostanie użyty, prawidłowy klient wykryje jego unieważnienie, co umożliwia wykrycie kradzieży tokenu.

RFC 7662 definiuje punkt końcowy introspekcji tokenów, który umożliwia serwerom zasobów odpytanie serwera autoryzacji o bieżący stan nieprzezroczystego tokenu dostępu (active/inactive), zakres, podmiot i czas wygaśnięcia. Introspekcja umożliwia unieważnianie tokenów w czasie rzeczywistym: gdy token zostanie unieważniony na serwerze autoryzacji, wywołania introspekcji natychmiast zwracają active: false.

RFC 7009 definiuje punkt końcowy unieważniania tokenów, który umożliwia klientom powiadomienie serwera autoryzacji, że token — dostępu lub odświeżający — powinien zostać unieważniony. Stosuje się go podczas wylogowywania lub po wykryciu przez klienta podejrzanej aktywności. Tokenów dostępu JWT nie można w pełni unieważnić bez listy unieważnień, ponieważ serwery zasobów weryfikują je lokalnie, bez kontaktowania się z serwerem autoryzacji.

Zakresy OAuth 2.0 definiują konkretne uprawnienia, o które prosi klient. Serwer autoryzacji przedstawia użytkownikowi żądane zakresy do zatwierdzenia. Serwery zasobów egzekwują wymagania dotyczące zakresów dla poszczególnych punktów końcowych. Obowiązuje zasada najmniejszych uprawnień: klienci powinni żądać wyłącznie minimalnych zakresów niezbędnych do działania, a serwery zasobów powinny odrzucać żądania z niewystarczającym zakresem.

Przepływ kodu autoryzacji jest właściwy dla aplikacji działających po stronie serwera. Przepływ niejawny został wycofany — należy zamiast niego używać PKCE. Przepływ ROPC został wycofany, ponieważ niweczy cel OAuth. Poświadczenia klienta służą do komunikacji M2M. Autoryzacja urządzenia obsługuje urządzenia o ograniczonych możliwościach wprowadzania danych. Tokeny dostępu mogą być nieprzezroczyste albo mieć format JWT. Tokeny odświeżające powinny podlegać rotacji. Introspekcja (RFC 7662) i unieważnianie (RFC 7009) uzupełniają zarządzanie tokenami.