OAuth wyjaśniony: role, przepływ PKCE i OAuth vs SAML
OAuth wyjaśniony
Czym jest OAuth? Role, przepływ PKCE, OAuth vs SAML vs OIDC | We.Inc
OAuth 2.0 prostymi słowami: cztery role, przepływ authorization code z PKCE krok po kroku, scopes oraz czym OAuth różni się od OpenID Connect i SAML.
OAuth 2.0 to standard, który pozwala jednej aplikacji działać w Twoim imieniu w innej usłudze, nigdy nie widząc Twojego hasła. Zatwierdzasz żądanie na stronie logowania samej usługi, a aplikacja dostaje access token ograniczony do zakresów (scopes), na które się zgodziłeś. OAuth zajmuje się autoryzacją; OpenID Connect dodaje na nim logowanie.
OAuth 2.0 vs OpenID Connect vs SAML 2.0
OAuth 2.0
OpenID Connect
SAML 2.0
Odpowiada na pytanie
Do czego ta aplikacja ma dostęp?
Kim jest ten użytkownik?
Kim jest ten użytkownik?
Główny artefakt
Access token
ID token (JWT) plus access token
Asercja XML
Specyfikacja
RFC 6749 (IETF)
OpenID Connect Core 1.0
OASIS SAML 2.0
Strony
Klient, serwer autoryzacji, serwer zasobów
Relying party, dostawca OpenID
Dostawca usługi, dostawca tożsamości
Typowe zastosowanie
Dostęp do API, "połącz swoje konto"
Przyciski "Zaloguj się przez", logowanie w aplikacjach mobilnych i SPA
Single sign-on w firmie
Przed OAuth połączenie dwóch usług często oznaczało wpisanie hasła do jednej z nich w drugiej. OAuth zastąpił to krótkotrwałymi tokenami o wąskim zakresie, wydawanymi dopiero po Twojej zgodzie. Poniższy generator tworzy w Twojej przeglądarce prawdziwy verifier i challenge PKCE oraz buduje URL autoryzacji, abyś zobaczył każdy parametr używany w przepływie.
Aplikacja tworzy losowy code_verifier, haszuje go do code_challenge i wysyła Cię do serwera autoryzacji z tym challenge, swoim client_id, zakresami i wartością state.
Logujesz się na stronie serwera autoryzacji i zatwierdzasz zakresy.
Serwer przekierowuje z powrotem na redirect_uri aplikacji z krótkotrwałym kodem autoryzacji i tym samym state.
Aplikacja sprawdza state, a potem wysyła kod i oryginalny code_verifier do token endpoint.
Serwer haszuje verifier, dopasowuje go do zapisanego challenge i zwraca access token, który aplikacja wysyła do API.
Używaj przepływu authorization code z PKCE zarówno w aplikacjach jednostronicowych, mobilnych, jak i serwerowych.
Zawsze wysyłaj i sprawdzaj state, który specyfikacja OAuth zaleca do ochrony przed cross-site request forgery.
Proś o najwęższe zakresy, które wystarczą do zadania; ludzie chętniej zatwierdzają małe prośby.
Rejestruj dokładne redirect URI. Wildcardy i otwarte przekierowania to klasyczny sposób kradzieży tokenów.
Trzymaj client secret wyłącznie na serwerze. Aplikacja w przeglądarce lub mobilna nie potrafi utrzymać sekretu.
Najczęściej zadawane pytania
OAuth to uwierzytelnianie czy autoryzacja?
Autoryzacja. Access token mówi, co aplikacja może zrobić, a nie kim jest użytkownik, i API może Ci tego nawet nie zdradzić. Gdy potrzebujesz tożsamości osoby, użyj OpenID Connect, który zwraca podpisany ID token z claimami takimi jak sub, iss, aud i exp.
Czym jest PKCE i czy go potrzebuję?
PKCE (RFC 7636) wiąże kod autoryzacji z aplikacją, która rozpoczęła przepływ. Aplikacja najpierw wysyła hash losowego sekretu, a później sam sekret, więc skradziony kod jest bezużyteczny. Używaj S256, który serwery muszą obsługiwać, zamiast plain.
Czym różni się OAuth od SAML?
SAML to starszy standard oparty na XML, w którym dostawca tożsamości wysyła podpisaną asercję o użytkowniku do dostawcy usługi, głównie na potrzeby firmowego single sign-on w przeglądarkach. OAuth wydaje tokeny do dostępu do API i dobrze sprawdza się w aplikacjach mobilnych i API. Bliższym odpowiednikiem logowania SAML w świecie OAuth jest OpenID Connect.
Czym są scopes?
Scopes (zakresy) to uprawnienia, o które prosi aplikacja, zapisane jako lista rozdzielonych spacjami ciągów znaków z rozróżnianiem wielkości liter, definiowanych przez serwer autoryzacji, na przykład openid email lub repo read:user. Ekran zgody je pokazuje, a token obejmuje tylko to, co zostało zatwierdzone.
Czy nadal używać implicit flow?
Nie w nowych projektach. Zwracał tokeny we fragmencie URL, skąd mogą wyciec przez historię i logi. Przepływ authorization code z PKCE daje aplikacjom przeglądarkowym tę samą wygodę bez takiego ryzyka.
Cztery role
RFC 6749 wymienia cztery strony. Właścicielem zasobu (resource owner) jesteś Ty. Klient to aplikacja prosząca o dostęp. Serwer autoryzacji sprawdza, kim jesteś, i wydaje tokeny. Serwer zasobów hostuje API, które przyjmuje te tokeny. Często jedna firma prowadzi oba serwery, ale to osobne zadania.
Po co istnieje wymiana kodu
Przekierowanie z powrotem do aplikacji przechodzi przez przeglądarkę, która jest nieszczelnym miejscem dla czegokolwiek cennego. Dlatego przekierowanie niesie tylko jednorazowy kod, który według zaleceń specyfikacji powinien wygasać w ciągu 10 minut. Właściwy token jest pobierany bezpośrednim wywołaniem token endpoint.
PKCE zamyka pozostałą lukę. Nawet jeśli malware lub logujący proxy przechwyci kod, nie zrealizuje go bez verifiera, który nigdy nie opuścił aplikacji.
Gdzie pasuje OpenID Connect
OpenID Connect to cienka warstwa na OAuth. Dodaj openid do zakresów, co specyfikacja OIDC czyni obowiązkowym, a odpowiedź z tokenem będzie zawierać także ID token: podpisany JWT opisujący użytkownika. Nonce wysłany w żądaniu i powtórzony w ID tokenie chroni przed atakiem powtórzeniowym.
Przepływ authorization code z PKCE
Każdy krok i parametry, które przenosi
Krok
Skąd dokąd
Kluczowe parametry
1. Żądanie autoryzacji
Aplikacja do serwera autoryzacji (przekierowanie w przeglądarce)
access_token, token_type, expires_in, opcjonalnie refresh_token (oraz id_token z OIDC)
6. Wywołanie API
Aplikacja do serwera zasobów
Authorization: Bearer <access_token>
PKCE w kodzie
Utwórz verifier i challenge S256 w przeglądarce
32 losowe bajty zakodowane jako base64url dają verifier o długości 43 znaków, najkrótszej, na jaką pozwala RFC 7636.
Wymień kod na tokeny
Uruchamiane po przekierowaniu. Najpierw porównaj state, a potem wyślij zapisany verifier razem z kodem.
Generator PKCE i URL autoryzacji
Tworzy świeży code_verifier i jego code_challenge S256 za pomocą kryptografii Twojej przeglądarki, a potem składa URL autoryzacji z Twoich ustawień. Nic nie jest wysyłane; poniższy endpoint to placeholder, który podmieniasz.
Endpoint autoryzacji
Zakresy (rozdzielone spacjami)
Nowy verifier
code_verifier (znaków: {n}, trzymaj w tajemnicy do kroku 4)