OAuth 2.0 and OpenID Connect security
Pentest OAuth 2.0 i OpenID Connect. Przepływy i tokeny pod kontrolą.
OAuth deleguje dostęp, a OpenID Connect dodaje warstwę tożsamości. Bezpieczny wynik zależy od zgodnych decyzji klienta, authorization servera i każdego API, które przyjmuje token.
Krótka odpowiedź
Pentest OAuth 2.0 i OpenID Connect sprawdza autoryzowane przepływy od żądania logowania lub zgody przez callback i wymianę kodu po walidację tokenu w resource serverze. Weryfikujemy redirect URI, PKCE, state, nonce, issuer, client authentication, scopes, audience, claims, JWKS, refresh, revocation, logout i zachowanie wielu dostawców. Test przypisuje każdą kontrolę do klienta, authorization servera albo API, zamiast oceniać sam wygląd ekranu logowania.
Wycena bez czekania
Sprawdź koszt i termin od razu.
Trzy odpowiedzi wystarczą do natychmiastowej kwalifikacji. E-mail podajesz dopiero wtedy, gdy chcesz odpowiedzi eksperta.
Dla kogo
Kiedy ten zakres ma sens?
- Aplikacje dodające logowanie przez OIDC
- API chronione tokenami OAuth 2.0
- Klienci web, SPA, mobile i machine-to-machine
- Platformy obsługujące wielu issuerów, tenantów albo klientów B2B
Zakres testu
Co sprawdzamy?
Klient i redirect URI
Rejestracja callbacków, dokładne dopasowanie adresu, typ klienta, przechowywanie sekretu, open redirects i powiązanie odpowiedzi z właściwą sesją.
Authorization Code i PKCE
Code challenge, verifier, S256, jednorazowość kodu, związanie z klientem i redirect URI oraz brak downgrade do słabszego przepływu.
State, nonce i issuer
Ochrona przed CSRF i pomieszaniem przepływów, unikalność wartości, walidacja issuer i obsługa klienta współpracującego z wieloma serwerami autoryzacji.
Tokeny i klucze
Podpis, dozwolone algorytmy, issuer, audience, czas, subject, typ tokenu, discovery, JWKS, cache i bezpieczna rotacja kluczy.
Scopes, claims i API
Minimalne uprawnienia, consent, mapowanie claims, scope wymagany przez operację i niezależna walidacja tokenu przez każdy resource server.
Refresh, revocation i logout
Rotacja i wykrywanie ponownego użycia refresh tokenu, ograniczenie odbiorcy, unieważnienie, wylogowanie, zakończenie sesji i zachowanie skradzionego tokenu.
Rezultat
Co dostajesz?
- Diagram klientów, issuerów, tokenów i resource serverów
- Macierz przepływ, client type, scope, audience i oczekiwana kontrola
- Ustalenia przypisane do klienta, authorization servera albo API
- Zalecenia odnoszące się do aktualnego OAuth Security BCP
- Jeden retest uzgodnionych poprawek
Inwentaryzacja ról protokołu
Zbieramy client IDs, typy klientów, issuer, discovery, redirect URI, granty, scopes, API i konta testowe bez przekazywania produkcyjnych sekretów.
Model przepływów
Rozpisujemy przeglądarkę lub aplikację, authorization server, callback, token endpoint, UserInfo, resource servery i granice tenantów.
Test walidacji
Sprawdzamy rozpoczęcie i zakończenie przepływu, wymianę kodu, tokeny, klucze, zakres dostępu, odświeżanie i wylogowanie w uzgodnionych scenariuszach.
Raport i retest
Łączymy wynik ze stroną odpowiedzialną za poprawkę, podajemy wymagane zachowanie i potwierdzamy je po wdrożeniu.
Cena i decyzja
Ile kosztuje pentest OAuth i OIDC?
Jeden klient, jeden issuer, jeden podstawowy przepływ i ograniczony zestaw scopes kosztują orientacyjnie 7 500-11 000 zł netto. Gotowy, mały zakres może kwalifikować się do trybu 24H za 9 000-13 000 zł netto. Wiele typów klientów, issuerów, resource serverów, grantów, tenantów i niestandardowe rozszerzenia wymagają osobnej macierzy przepływów.
Sprawdź własny zakres ↗FAQ
Najczęstsze pytania
Czym różni się OAuth od OpenID Connect?+
OAuth 2.0 służy do delegowania dostępu do zasobów. OpenID Connect wykorzystuje OAuth i dodaje standardową warstwę uwierzytelnienia oraz ID Token z informacją o zdarzeniu logowania i użytkowniku.
Czy samo użycie PKCE zabezpiecza cały przepływ?+
Nie. PKCE chroni kod autoryzacyjny przed określonymi klasami nadużyć, ale nadal trzeba poprawnie sprawdzić redirect URI, issuer, state lub nonce, tokeny, scopes, audience, klienta i zachowanie API.
Czy test obejmuje authorization server i API?+
Obejmuje te elementy, które należą do pisemnie autoryzowanego zakresu. Gdy używany jest zewnętrzny IdP, testujemy własną konfigurację i integrację bez działań wykraczających poza warunki dostawcy.
Czy potrzebujemy przekazać client secret?+
Nie przesyłaj produkcyjnych sekretów przez formularz. Najlepiej utworzyć testowego klienta i wprowadzić sekret bezpośrednio w uzgodnionym, bezpiecznym kanale albo wykonać konfigurację wspólnie przed startem.
Czy testujecie klientów SPA, mobile i machine-to-machine?+
Tak, ale są to różne modele zagrożeń. Zakres zapisuje typ klienta, możliwość utrzymania sekretu, grant, redirect URI, sposób przechowywania tokenów i resource servery, do których klient ma dostęp.