Serwer autoryzacyjny wydaje token dostępu, który serwer zasobów akceptuje pod zdefiniowanymi warunkami. Klient może działać w imieniu użytkownika po delegowanej autoryzacji lub we własnym imieniu w przepływie maszyna–maszyna.
OAuth definiuje role i przepływy protokołu, a nie jeden format tokenu czy uniwersalny model uprawnień. Dla aplikacji zwróconych do użytkownika aktualne praktyki bezpieczeństwa faworyzują przepływ z kodem autoryzacyjnym z Proof Key for Code Exchange (PKCE). Implementacje muszą wiązać odpowiedzi z właściwym klientem i URI przekierowania, chronić kody autoryzacyjne i tokeny odświeżania oraz zapewniać, że tokeny dostępu są akceptowane tylko przez zamierzone serwery zasobów.
Najważniejsze punkty
Kluczowe roleRozróżniaj właściciela zasobu, klienta, serwer autoryzacyjny i serwer zasobów; dokumentuj, gdy jeden komponent pełni więcej niż jedną rolę.
Kontrole tokenówOgraniczaj odbiorcę, zakres, czas życia i przechowywanie; waliduj tokeny w pełni; rotuj lub unieważniaj tokeny odświeżania tam, gdzie stosowne; i unikaj eksponowania tokenów bearer w URL-ach lub logach.
Aktualne wybory przepływówPrzestrzegaj najlepszej aktualnej praktyki bezpieczeństwa OAuth: klienci nie powinni używać grantu implicit poza przypadkami, gdzie jego określone ryzyka wstrzyknięcia i wycieku są złagodzone, i nie mogą używać grantu poświadczeń hasłowych właściciela zasobu.
Istotne ograniczenieOAuth 2.0 nie definiuje uwierzytelniania użytkownika ani nie dowodzi, kto używa tokena dostępu. Ważny token nie zastępuje też autoryzacji na poziomie obiektu, funkcji lub transakcji wewnątrz serwera zasobów.