OAuth 2.0 bezpiecznie — najważniejsze zasady RFC 9700

Bezpieczeństwo OAuth 2.0 nie sprowadza się do poprawnego podpisania JWT. Najczęstsze incydenty powstają przez luźne dopasowanie adresu przekierowania, brak PKCE, token przeznaczony dla innej usługi, niekontrolowany refresh token albo niebezpieczny legacy flow. RFC 9700 zbiera aktualne Best Current Practice i zastępuje część zaleceń znanych ze starszych dokumentów.

Ten poradnik przekłada standard na checklistę dla aplikacji webowej, mobilnej, SPA oraz API.

Authorization Code z PKCE jako domyślna ścieżka

Authorization Code Flow oddziela interakcję przeglądarki od wymiany kodu na token. PKCE wiąże kod z klientem, który rozpoczął logowanie: aplikacja wysyła hash losowego code_verifier, a przy wymianie musi przedstawić oryginał. Przechwycony kod bez weryfikatora staje się znacznie mniej użyteczny.

PKCE jest wymagane dla klientów publicznych, takich jak aplikacje mobilne i SPA, ale warto stosować je także dla klientów poufnych. Używaj metody S256, generuj weryfikator kryptograficznie i nigdy nie zapisuj go w logach.

Implicit Grant oraz Resource Owner Password Credentials nie powinny być wybierane dla nowych wdrożeń. Pierwszy eksponuje token w kanale przeglądarki, drugi przekazuje aplikacji hasło użytkownika i omija nowoczesne mechanizmy dostawcy tożsamości.

Redirect URI musi pasować dokładnie

Serwer autoryzacyjny powinien porównywać pełny, wcześniej zarejestrowany redirect URI. Wildcard, dopasowanie prefiksu albo parametr sterujący końcowym adresem tworzą drogę do kradzieży kodu.

Każde środowisko powinno mieć osobny zestaw adresów. Nie rejestruj produkcyjnego klienta dla dowolnego localhost, domen testowych i wszystkich subdomen. Dla aplikacji mobilnych preferuj Universal Links lub App Links powiązane z kontrolowaną domeną.

Parametr state wiąże odpowiedź z rozpoczętą sesją i pomaga chronić przed CSRF. W OpenID Connect używaj także nonce do powiązania ID tokenu z żądaniem.

Ogranicz token do właściwego odbiorcy

Resource server musi zweryfikować podpis, wystawcę, audience, czas ważności oraz wymagany scope. Token wystawiony dla API A nie może zostać zaakceptowany przez API B tylko dlatego, że podpisał go ten sam dostawca.

Scope opisuje dozwoloną operację, ale nie zastępuje autoryzacji obiektu. Endpoint nadal sprawdza użytkownika, tenant, właściciela i stan zasobu. Błędy BOLA oraz kontroli funkcji omawiamy w checkliście pentestu API.

Tokeny dostępowe powinny być krótkotrwałe. Dla scenariuszy wyższego ryzyka rozważ tokeny związane z klientem, np. DPoP lub mTLS, które utrudniają replay po kradzieży.

Refresh token: rotacja i wykrywanie replay

Długowieczny refresh token bywa cenniejszy niż hasło. Klient publiczny powinien otrzymywać token rotowany: po każdej wymianie stary przestaje być prawidłowy. Ponowne użycie starego tokenu jest sygnałem kradzieży i powinno unieważnić całą rodzinę.

Przechowuj refresh token w mechanizmie platformy przeznaczonym dla sekretów. W aplikacji webowej używaj bezpiecznej sesji serwerowej lub cookie HttpOnly, Secure i właściwego SameSite. Nie umieszczaj tokenów w URL, localStorage, logach, narzędziach analitycznych ani raportach błędów.

Checklista OAuth 2.0 dla zespołu

• Authorization Code + PKCE S256 jest domyślnym flow.
• Redirect URI jest dopasowywany dokładnie.
• state i nonce są generowane losowo i weryfikowane.
• API sprawdza iss, aud, czas i scope.
• Tokeny mają minimalne uprawnienia i krótki czas życia.
• Refresh tokeny są rotowane, a replay uruchamia unieważnienie.
• Klienci poufni uwierzytelniają się bez sekretu wpisanego do kodu frontendu.
• Logi i telemetryka redagują kody oraz tokeny.
• Wylogowanie, blokada konta i incydent umożliwiają skuteczne cofnięcie dostępu.
• Każda aplikacja i środowisko ma osobną rejestrację klienta.

Jak testować OAuth

Test obejmuje więcej niż poprawne logowanie. Podmień redirect URI, powtórz kod, spróbuj użyć tokenu dla innego audience, pomiń PKCE, odtwórz refresh token i zmień konto w trakcie łączenia tożsamości. Sprawdź również błędy na gatewayu i w każdym resource serverze.

RFC 9700 jest punktem odniesienia, ale końcowe bezpieczeństwo zależy od konkretnego dostawcy i logiki aplikacji. Jeśli potrzebujesz zweryfikować przepływy OAuth, OIDC i tokeny w praktyce, skontaktuj się z nami.

---

Testy negatywne przepływu

Nie ograniczaj testu do poprawnego logowania. Podmień redirect_uri, ponów kod, zmień klienta, użyj kodu bez właściwego verifiera PKCE, odtwórz token i sprawdź mieszanie odpowiedzi między issuerami. Serwer musi porównywać przekierowanie dokładnie z zarejestrowaną wartością i wiązać kod z klientem oraz transakcją.

Token ogranicz przez audience, scope i krótki czas życia; dla wyższego ryzyka rozważ token sender-constrained. Refresh tokeny wymagają rotacji lub innego mechanizmu wykrywania odtworzenia zgodnego z BCP. Loguj identyfikatory i wynik walidacji bez zapisywania samych tokenów. Migracja starego flow powinna mieć telemetrię użycia i termin wyłączenia.

Źródła: RFC 9700, RFC 7636 — PKCE, OWASP API Security.