OAuth 2.0 i OIDC: bezpieczeństwo nowoczesnego uwierzytelniania

OAuth 2.0 w prostych słowach

OAuth 2.0 to framework autoryzacji, a nie protokół uwierzytelniania. To rozróżnienie ma ogromne znaczenie: OAuth odpowiada na pytanie „do czego ta aplikacja ma dostęp?”, a nie „kim jest ten użytkownik?”. Jego kluczowym zastosowaniem jest delegowany dostęp: pozwala aplikacji zewnętrznej czytać Twoje pliki na Dysku Google, nie poznając nigdy Twojego hasła do Google.

Główni uczestnicy OAuth:

• Właściciel zasobu (Resource Owner): użytkownik, do którego należą dane
• Klient (Client): aplikacja zewnętrzna prosząca o dostęp
• Serwer autoryzacji (Authorization Server): wydaje tokeny po wyrażeniu zgody przez użytkownika (np. serwer uwierzytelniania Google)
• Serwer zasobów (Resource Server): API przechowujące dane użytkownika (np. API Dysku Google)

Serwer autoryzacji wydaje token dostępu (Access Token), którego klient używa do wywoływania serwera zasobów w imieniu użytkownika. Tokeny to zwykle krótkotrwałe tokeny JWT lub nieprzejrzyste ciągi znaków.

Przepływ Authorization Code

Dla aplikacji webowych działających po stronie serwera zalecanym podejściem jest przepływ Authorization Code:

1. Klient przekierowuje użytkownika do serwera autoryzacji z parametrami response_type=code, client_id, redirect_uri, scope i losowym state
2. Użytkownik uwierzytelnia się i wyraża zgodę
3. Serwer autoryzacji przekierowuje z powrotem na redirect_uri klienta z krótkotrwałym code i wartością state
4. Klient sprawdza, czy state zgadza się z wysłanym (ochrona przed CSRF), a następnie wymienia code na tokeny przez żądanie POST kanałem zwrotnym, używając swojego client_secret
5. Serwer autoryzacji zwraca access_token oraz opcjonalnie refresh_token i id_token

To wymiana kanałem zwrotnym (krok 4) czyni ten przepływ bezpiecznym — token dostępu nigdy nie pojawia się w adresie URL ani w historii przeglądarki.

PKCE: zabezpieczanie klientów publicznych

Aplikacje mobilne i SPA (aplikacje jednostronicowe) nie mogą bezpiecznie przechowywać client_secret — byłby widoczny w pliku aplikacji lub w kodzie JavaScript. Rozwiązaniem jest PKCE (Proof Key for Code Exchange, wymawiane „piksi”):

1. Klient generuje losowy code_verifier i wyprowadza z niego code_challenge = BASE64URL(SHA256(code_verifier))
2. code_challenge jest wysyłany w żądaniu autoryzacji
3. code_verifier jest wysyłany przy wymianie na token
4. Serwer autoryzacji sprawdza zależność — tylko pierwotny klient może dokończyć wymianę

W 2026 roku PKCE należy stosować dla wszystkich klientów OAuth, także poufnych. Zapewnia ochronę nawet wtedy, gdy kod autoryzacji zostanie przechwycony.

OpenID Connect (OIDC): dodanie uwierzytelniania

OIDC to cienka warstwa tożsamości zbudowana na OAuth 2.0. Dodaje ID Token — token JWT podpisany przez serwer autoryzacji, zawierający oświadczenia o uwierzytelnionym użytkowniku (sub, email, name itp.). To dzięki OIDC „Zaloguj się przez Google” rzeczywiście uwierzytelnia użytkowników, a nie tylko autoryzuje dostęp do ich danych.

Kluczowe pojęcia OIDC:

• ID Token: token JWT, dzięki któremu klient weryfikuje, kim jest użytkownik — nigdy nie wysyłaj go do API
• Access Token: do wywoływania API serwera zasobów — klient powinien traktować go jako nieprzejrzysty
• Endpoint UserInfo: endpoint API zwracający oświadczenia o użytkowniku po wywołaniu z tokenem dostępu
• nonce: losowa wartość dołączana do żądania autoryzacji i weryfikowana w ID Tokenie, by zapobiec atakom powtórzeniowym

Typowe podatności i ataki

Otwarte przekierowanie przez redirect_uri

Jeśli serwer autoryzacji nie weryfikuje ściśle redirect_uri, atakujący może zmienić go na adres własnego serwera i ukraść kod autoryzacji, gdy ofiara wyrazi zgodę. Obrona: rejestruj dokładne adresy przekierowań; nie dopuszczaj symboli wieloznacznych ani dopasowywania wzorców.

CSRF przez parametr state

Pominięcie lub brak weryfikacji parametru state pozwala atakującemu nakłonić przeglądarkę ofiary do dokończenia przepływu autoryzacji zainicjowanego przez atakującego, co może powiązać konto ofiary z tożsamością atakującego. Obrona: zawsze generuj kryptograficznie losowy state i weryfikuj go po powrocie.

Wyciek tokenów przez nagłówek Referer

Przepływ Implicit (obecnie wycofany) zwracał tokeny bezpośrednio we fragmencie adresu URL, skąd mogły wyciec przez nagłówki Referer lub historię przeglądarki. Obrona: nigdy nie używaj przepływu Implicit — stosuj Authorization Code + PKCE.

Ataki na pomyłki w JWT

Tokeny JWT są samowystarczalne i muszą być starannie weryfikowane. Typowe błędy:

• Akceptowanie alg: none — wyłącz negocjowanie algorytmu i zawsze jawnie określaj dozwolone algorytmy
• Używanie klucza publicznego RS256 jako sekretu HS256 — ustal oczekiwany algorytm po stronie serwera
• Brak weryfikacji oświadczeń iss, aud i exp

Niewystarczająca weryfikacja zakresów

Tokeny dostępu powinny mieć zakres ograniczony do niezbędnych uprawnień. API muszą sprawdzać, czy przedstawiony token ma wymagany zakres dla każdej operacji — nie zakładaj, że ważny token oznacza pełny dostęp.

Lista kontrolna bezpiecznego wdrożenia

• Używaj Authorization Code + PKCE dla wszystkich klientów
• Rejestruj dokładne adresy przekierowań, wyłącznie HTTPS
• Zawsze weryfikuj parametr state (lub używaj PKCE, które daje równoważną ochronę)
• Weryfikuj wszystkie oświadczenia JWT: iss, aud, exp, nbf i algorytm
• W SPA przechowuj tokeny w pamięci (nie w localStorage) — w aplikacjach webowych używaj ciasteczek HttpOnly dla tokenów odświeżania
• Wdróż rotację tokenów: przy każdym użyciu wydawaj nowy token odświeżania i unieważniaj stary
• Stosuj krótkotrwałe tokeny dostępu (5–15 minut) z tokenami odświeżania dla ciągłości sesji
• Regularnie audytuj wszystkie aplikacje OAuth z dostępem do Twojego serwera autoryzacji
• Nigdy nie loguj ani nie ujawniaj tokenów dostępu w adresach URL, logach czy komunikatach błędów