Folosește fluxul Authorization Code cu PKCE pentru toți clienții

Subiect din roadmap-ul Bune practici: securitatea API-urilor · parte din „Autentificare”

Practica „Folosește fluxul Authorization Code cu PKCE pentru toți clienții” înseamnă adoptarea standardului OAuth 2.1 pentru autentificare și autorizare, eliminând necesitatea stocării secretelor client pe dispozitivele utilizatorilor. PKCE (Proof Key for Code Exchange) adaugă un strat suplimentar de securitate generând o cheie criptografică unică la fiecare sesiune, ceea ce previne atacurile de interceptare a codului de autorizare. Ignorarea acestei practici expune aplicația la riscuri majore, cum ar fi furtul token-urilor de acces sau reutilizarea lor de către atacatori, mai ales în cazul aplicațiilor mobile sau Single Page Applications (SPA).

Cum o aplici

  1. Generează un verifier și un challenge: La inițierea autentificării, creează un string aleatoriu (code_verifier) și calculează hash-ul său SHA256 pentru a obține code_challenge.
  2. Redirecționează utilizatorul: Trimite utilizatorul către provider-ul de identitate (ex: Google, GitHub) includând parametrii code_challenge, code_challenge_method=S256 și scope.
  3. Schimbă codul pentru token: După ce utilizatorul acceptă accesul, serverul tău primește code și code_verifier. Trimite aceste valori către endpoint-ul de token pentru a obține access_token.
  4. Validare server-side: Provider-ul verifică dacă hash-ul primit se potrivește cu cel calculat din code_verifier. Dacă da, eliberează token-urile.

Exemplu

Varianta greșită (Implicit Flow - periculos):

GET https://provider.com/authorize?response_type=token&client_id=XYZ

Aici, token-ul de acces este returnat direct în URL, fiind vizibil în istoricul browserului și în logs.

Varianta corectă (Authorization Code + PKCE):

# Pasul 1: Redirecționare
GET https://provider.com/authorize?
    response_type=code&
    client_id=XYZ&
    redirect_uri=https://app.me/callback&
    code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&
    code_challenge_method=S256

# Pasul 2: Schimbul de token (Server-to-Server)
POST https://provider.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=SplxlOBeZQQYbYS6WxSbIA&
redirect_uri=https://app.me/callback&
client_id=XYZ&
code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Cum verifici

  • Audit de configurare: Verifică în consola provider-ului de identitate că tipul aplicației este setat corect și că nu sunt activate fluxuri învechite precum implicit.
  • Teste de penetrare: Folosește instrumente precum OWASP ZAP sau Burp Suite pentru a intercepta traficul și a confirma că code_verifier este trimis doar către serverul backend și nu apare în URL sau localStorage.
  • Monitorizare logs: Caută erori de tip invalid_grant sau invalid_client care pot indica încercări de replay attack sau configurare incorectă a PKCE.

Greșeli frecvente

  1. Stocarea code_verifier în frontend: Verifier-ul trebuie generat și păstrat exclusiv pe server pentru a schimba codul. Dacă este expus în browser, atacatorul îl poate folosi pentru a intercepta sesiunea.
  2. Utilizarea fluxului Implicit: Mulți dezvoltatori continuă să folosească response_type=token din motive de comoditate, deși este considerat nesigur și depreciat în OAuth 2.1.
  3. Neglijarea validării state: Deși PKCE protejează împotriva interceptării codului, parametrul state este încă esențial pentru a preveni atacurile CSRF (Cross-Site Request Forgery) în timpul redirecționării.

Resurse gratuite

Alte subiecte din „Autentificare”