Cyber Security Academy · Lekcja

Przepływy OAuth 2.0

Granty autoryzacyjne i tokeny

Lekcja 1 z 413 kroki

Przepływy OAuth 2.0 to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cyber Security Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Jaki problem faktycznie rozwiązuje OAuth 2.0

OAuth 2.0 to framework delegowanej autoryzacji. Pozwala użytkownikowi przyznać aplikacji zewnętrznej ograniczony dostęp do zasobów w innej usłudze bez udostępniania hasła.

Dotyczy autoryzacji (czyli tego, co aplikacja może zrobić), a nie uwierzytelniania (czyli tego, kim jest użytkownik).
Aplikacja otrzymuje ograniczony zakresem access_token, nigdy zaś dane uwierzytelniające użytkownika.

Osoby odpowiedzialne za bezpieczeństwo muszą pamiętać: samo OAuth nie potwierdza tożsamości. Traktowanie tokenu dostępu jako dowodu zalogowania to klasyczny błąd, któremu zaradza OIDC.

Cztery role

Każdy przepływ OAuth obejmuje cztery role. Ich prawidłowe odwzorowanie ma kluczowe znaczenie dla modelowania zagrożeń.

Właściciel zasobu — użytkownik, do którego należą dane.
Klient — aplikacja żądająca dostępu.
Serwer autoryzacji (AS) — wydaje tokeny po uzyskaniu zgody.
Serwer zasobów (RS) — API przechowujące chronione dane i weryfikujące tokeny.

Granice zaufania przebiegają między tymi rolami. Przejęty klient lub zbyt liberalny AS podważa cały łańcuch zaufania.

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

Grant typu Authorization Code

Grant Authorization Code to zalecany przepływ dla aplikacji webowych i mobilnych. Oddziela przekierowanie widoczne dla użytkownika od poufnej wymiany tokenu.

Użytkownik jest przekierowywany do AS, aby się uwierzytelnić i wyrazić zgodę.
AS zwraca krótkotrwały code do zarejestrowanego URI przekierowania.
Klient wymienia kod (po stronie serwera) na tokeny za pośrednictwem kanału zwrotnego.

Ponieważ tokeny są uzyskiwane przez kanał zwrotny, nigdy nie pojawiają się na pasku adresu ani w historii przeglądarki.

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE: Proof Key for Code Exchange

PKCE (RFC 7636) wzmacnia grant Authorization Code i jest obecnie zalecane dla wszystkich klientów, także poufnych.

Klient generuje losowy code_verifier i wysyła jego skrót jako code_challenge.
Podczas wymiany tokenu klient musi przedstawić oryginalny weryfikator.

Dzięki temu kod jest powiązany z pierwotnym klientem, co uniemożliwia jego wykorzystanie przez atakującego, który przechwycił kod autoryzacyjny.

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

Grant Client Credentials

Grant Client Credentials służy do dostępu machine-to-machine, gdy nie uczestniczy w nim żaden użytkownik (np. usługa backendowa wywołująca API).

Klient uwierzytelnia się za pomocą własnych poświadczeń i otrzymuje token dostępu.
Zwykle nie ma tu zgody użytkownika ani tokenu odświeżającego.

Zakres tych tokenów należy ściśle ograniczyć, a sekrety klienta regularnie rotować. Nie wolno używać tego przepływu do podszywania się pod użytkowników końcowych.

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

Tokeny dostępu a tokeny odświeżające

OAuth wydaje dwa główne typy tokenów, które mają zupełnie różny czas życia i wymagają odmiennych zasad obsługi.

Token dostępu — krótkotrwały, wysyłany do serwera zasobów przy każdym wywołaniu. Należy traktować go jako poświadczenie typu bearer.
Token odświeżający — długotrwały, używany wyłącznie wobec AS do uzyskiwania nowych tokenów dostępu.

Tokeny odświeżające mają wysoką wartość. Należy przechowywać je bezpiecznie, wiązać je z klientem i obsługiwać ich unieważnianie.

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

Tokeny typu bearer i transport

Większość tokenów dostępowych OAuth to tokeny typu bearer: każdy, kto je posiada, może ich użyć — podobnie jak gotówki.

Należy zawsze przesyłać je przez TLS; nigdy w adresach URL, gdzie mogą wyciec do logów i nagłówków referrer.
Należy przesyłać je w nagłówku Authorization.
W przypadku interfejsów API wysokiego ryzyka warto rozważyć tokeny powiązane z nadawcą (DPoP, mTLS).

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

Grant Implicit jest przestarzały

Starszy grant Implicit zwracał tokeny bezpośrednio we fragmencie URI przekierowania. Obecnie jest odradzany przez OAuth 2.0 Security BCP i usunięty w OAuth 2.1.

Tokeny wyciekały przez historię przeglądarki, nagłówki referrer i logi.
Brak kanału zwrotnego oznaczał słabsze uwierzytelnianie klienta.

Zamiast tego w aplikacjach SPA należy używać Authorization Code with PKCE.

Parametr state i CSRF

Parametr state chroni etap przekierowania przed atakiem CSRF. Klient generuje losową wartość, zapisuje ją w sesji i weryfikuje podczas wywołania zwrotnego.

Jeśli zwrócony parametr state nie pasuje, należy odrzucić odpowiedź.
Zapobiega to wstrzyknięciu przez atakującego jego własnego kodu autoryzacyjnego do sesji ofiary.

before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

Zakresy i zasada najmniejszych uprawnień

Zakresy określają szczegółowość dostępu przyznawanego przez token. Zasadę najmniejszych uprawnień należy stosować na każdym etapie.

Należy żądać tylko zakresów wymaganych przez daną funkcję (read:profile, a nie admin).
Serwery zasobów muszą egzekwować zakres na każdym punkcie końcowym, a nie tylko ufać ważnemu tokenowi.

Zbyt szeroka zgoda jest częstym zagrożeniem w rzeczywistych systemach: użytkownicy zatwierdzają aplikacje, które proszą o znacznie więcej uprawnień, niż potrzebują.

Typowe błędne konfiguracje OAuth

Większość incydentów związanych z OAuth wynika z konfiguracji, a nie z samego protokołu.

Otwarty redirect / zbyt luźne dopasowanie redirect_uri umożliwia atakującym kradzież kodów.
Brak parametru state lub PKCE umożliwia CSRF i wstrzykiwanie kodów.
Długotrwałe tokeny dostępowe bez możliwości unieważnienia.
Traktowanie tokenu dostępowego jako potwierdzenia uwierzytelnienia.

Należy rejestrować dokładne URI przekierowania i rygorystycznie je weryfikować.

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

Szybki test: zabezpieczanie uwierzytelniania SPA

Należy wybrać poprawny, nowoczesny przepływ dla poniższego scenariusza.

Odpowiedz w interaktywnej lekcji

Podsumowanie: przepływy OAuth 2.0

Najważniejsze informacje:

OAuth 2.0 zapewnia delegowane uprawnienia, a nie uwierzytelnianie.
Cztery role: właściciel zasobu, klient, serwer autoryzacji i serwer zasobów.
Authorization Code + PKCE to domyślne rozwiązanie dla aplikacji internetowych, mobilnych i SPA.
Client Credentials obsługuje dostęp między maszynami.
Należy stosować ochronę za pomocą state, ścisłego dopasowania URI przekierowania, krótkotrwałych tokenów dostępowych i TLS wszędzie.
Granty Implicit i Password są przestarzałe.

Bezpłatny start

Ucz się Cyber Security Academy dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy: 76
Lekcje: 303

Zacznij naukę bezpłatnie Wyświetl pełny kurs

Często zadawane pytania

Czy lekcja „Przepływy OAuth 2.0” jest bezpłatna?

Tak — pełny tekst „Przepływy OAuth 2.0” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cyber Security Academy, przejdź na CoddyKit PRO. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Przepływy OAuth 2.0”?

Granty autoryzacyjne i tokeny Ćwiczysz Cyber Security Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cyber Security Academy?

Nie wymagamy żadnego doświadczenia. Cyber Security Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „Przepływy OAuth 2.0”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cyber Security Academy?

Tak. Każda lekcja Cyber Security Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Przepływy OAuth 2.0
OpenID Connect (OIDC)
SAML i federacja
Ataki na tokeny i wzmacnianie zabezpieczeń

← Powrót do Cyber Security Academy