JWT, OAuth 2.0 i OIDC

Co to jest JWT (JSON Web Token) i jak działa autentykacja?

JWT (JSON Web Token): otwarty standard (RFC 7519) do przesyłania danych jako JSON object podpisany kryptograficznie. Struktura JWT: Header.Payload.Signature (oddzielone kropkami, base64url encoded). Header: algorytm (HS256, RS256, ES256) i typ (JWT). Payload (Claims): sub (subject/user ID), iss (issuer), aud (audience), exp (expiration), iat (issued at), custom claims. Signature: HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret). Jak działa: klient wysyła credentials. Serwer generuje JWT i zwraca. Klient przechowuje JWT (localStorage, cookie, memory). Klient wysyła JWT w każdym requeście: Authorization: Bearer {token}. Serwer weryfikuje podpis (bez bazy danych). Zalety JWT: stateless (brak sesji w DB). Skaluje się poziomo. Działa cross-domain. Samowystarczalny (dane w tokenie). Wady JWT: nie można unieważnić przed exp (bez blacklist). Większy rozmiar niż session ID. Sensitive data w payload (base64 nie jest encrypted!). exp zbyt długi = security risk. Access token (krótki TTL: 15min-1h) + Refresh token (długi TTL: 7-30 dni). Refresh token rotation: nowy refresh token przy każdym użyciu. Przechowywanie: HttpOnly cookie (bezpieczniejszy) vs localStorage (XSS risk).

OAuth 2.0 — flows, grant types i kiedy używać?

OAuth 2.0: framework autoryzacji (RFC 6749), nie autentykacji. Deleguje dostęp do zasobów bez udostępniania hasła. Aktorzy: Resource Owner (user), Client (aplikacja), Authorization Server (Google/GitHub), Resource Server (API). Grant Types: Authorization Code (+ PKCE): dla web apps i SPA. Redirect do auth server -> code -> exchange for tokens. Najbezpieczniejszy. Implicit: przestarzały (deprecated). Tylko dla SPA bez backendu. Nie używać. Client Credentials: serwis-do-serwisu (machine-to-machine). Brak user involvement. Device Code: TV, CLI tools bez przeglądarki. Resource Owner Password: przestarzały. Tylko legacy. PKCE (Proof Key for Code Exchange): rozszerzenie Authorization Code dla public clients (SPA, mobile). code_verifier (random string) + code_challenge (SHA256 hash). Zapobiega CSRF i authorization code interception. Scopes: granularne uprawnienia. openid, profile, email (OIDC). read:users, write:posts (custom). Tokens: Access Token (krótkoterminowy, dostęp do API). Refresh Token (długoterminowy, nowy access token). ID Token (OIDC — informacje o userze). OAuth vs autentykacja: OAuth = 'mogę...' (autoryzacja). Nie mówi kto jest user. OIDC = OAuth + autentykacja (who are you). Popularne OAuth providers: Google, GitHub, Microsoft, Facebook, Apple.

OpenID Connect (OIDC) — tożsamość ponad OAuth 2.0?

OIDC: protokół autentykacji zbudowany na OAuth 2.0 (2014). OAuth 2.0 + Identity Layer = OIDC. ID Token: JWT z danymi użytkownika. sub, name, email, picture, email_verified. Wydawany przez Authorization Server razem z Access Token. UserInfo Endpoint: GET /userinfo z Access Token. Zwraca profil użytkownika. Bardziej aktualne dane niż ID Token. Discovery: /.well-known/openid-configuration. Automatyczna konfiguracja klienta. Klucze publiczne do weryfikacji podpisów. Flows OIDC: Authorization Code (recommended). Implicit (deprecated). Hybrid. Kluczowe parametry: response_type=code, scope=openid profile email, nonce (anti-replay), state (CSRF protection). Claims: Standard (sub, name, email, phone, address, birthdate). Custom (role, tenant_id, plan). Rozszerzone: address, phone. OIDC vs SAML: OIDC — modern, JSON/JWT, REST, mobile/SPA-friendly. SAML 2.0 — enterprise legacy, XML, SSO dla starszych aplikacji. SAML nadal w enterprise (Okta, Azure AD, ADFS). Implementacje: Keycloak (open source, self-hosted). Auth0, Okta, Azure AD B2C (cloud). Supabase Auth, Clerk (developer-focused). Passport.js, openid-client (Node.js). Session vs JWT: Session — stateful, database lookup, HttpOnly cookie. JWT — stateless, no DB, Bearer token. Hybrydowe: session cookie zawierający JWT.

Session-based auth vs JWT — kiedy co wybrać?

Session-based authentication: serwer tworzy session ID po logowaniu. Session ID w cookie (HttpOnly, Secure, SameSite). Przy każdym requeście: sprawdź session w DB/Redis. Stan sesji w DB (session store). Zalety session: natychmiastowe unieważnienie (logout, ban). Mniejszy cookie (tylko ID). Server-side kontrola. Bezpieczniejszy out-of-the-box (HttpOnly cookie). Wady session: stateful — skalowanie wymaga shared session store (Redis). Każdy request = DB lookup. Trudniejsze w multi-domain. JWT authentication: token stateless. Weryfikacja kryptograficzna bez DB. Bearer token lub cookie. Zalety JWT: stateless (brak DB). Skalowanie łatwiejsze. Cross-domain. Microservices friendly. Wady JWT: brak natychmiastowego revocation. Payload widoczny (base64). Większy niż session ID. Implementacja revocation: short-lived access token + refresh token. Token blacklist (Redis) — niweluje zaletę stateless. Rekomendacja 2024: aplikacje web z jedną domeną -> session cookie (HttpOnly). SPA + API osobne domeny -> JWT (krótki TTL) + refresh token. Microservices -> JWT. Enterprise SSO -> OIDC/SAML. CSRF protection: session -> SameSite cookie lub CSRF token. JWT in cookie -> SameSite=Strict. JWT in Authorization header -> naturalnie odporny na CSRF.

Bezpieczeństwo autentykacji — CSRF, XSS, token storage i best practices?

XSS (Cross-Site Scripting): złośliwy JS może ukraść localStorage. localStorage — podatny na XSS (window.localStorage dostępny przez JS). Cookie HttpOnly — odporny (JS nie może czytać). Rekomendacja: tokeny w HttpOnly cookies. Jeśli localStorage — Content Security Policy (CSP) header. CSRF (Cross-Site Request Forgery): fałszywy request z innej domeny. Atakuje cookie (automatycznie wysyłane). Ochrona: SameSite=Strict lub Lax cookie. Double Submit Cookie pattern. CSRF token w formularzu. Authorization header (JWT) — odporny. SameSite cookie: Strict — tylko same-site (wyklucza cross-site linki). Lax — same-site + top-level navigation GET. None — wszystkie (wymaga Secure). Token rotation best practices: refresh token rotation (nowy refresh przy każdym użyciu). Wykrywanie reuse (replay attack). Revoke family przy wykryciu reuse. Token storage strategia: access token — memory (React state/closure). refresh token — HttpOnly cookie. PKCE — zawsze dla public clients (SPA, mobile). Rate limiting logowania: limit prób logowania. CAPTCHA po N nieudanych próbach. Account lockout. MFA (Multi-Factor Authentication): TOTP (Google Authenticator, Authy). WebAuthn/Passkeys (klucze sprzętowe, biometria). SMS OTP (mniej bezpieczny). Passkeys: W3C WebAuthn. Klucz kryptograficzny na urządzeniu. Phishing-resistant. Coraz popularniejsze (Apple, Google, Microsoft).

Wyślij zapytanie