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
- 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ținecode_challenge. - Redirecționează utilizatorul: Trimite utilizatorul către provider-ul de identitate (ex: Google, GitHub) includând parametrii
code_challenge,code_challenge_method=S256șiscope. - Schimbă codul pentru token: După ce utilizatorul acceptă accesul, serverul tău primește
codeșicode_verifier. Trimite aceste valori către endpoint-ul de token pentru a obțineaccess_token. - 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_verifiereste trimis doar către serverul backend și nu apare în URL sau localStorage. - Monitorizare logs: Caută erori de tip
invalid_grantsauinvalid_clientcare pot indica încercări de replay attack sau configurare incorectă a PKCE.
Greșeli frecvente
- 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. - Utilizarea fluxului Implicit: Mulți dezvoltatori continuă să folosească
response_type=tokendin motive de comoditate, deși este considerat nesigur și depreciat în OAuth 2.1. - Neglijarea validării
state: Deși PKCE protejează împotriva interceptării codului, parametrulstateeste încă esențial pentru a preveni atacurile CSRF (Cross-Site Request Forgery) în timpul redirecționării.
Resurse gratuite
Alte subiecte din „Autentificare”
- Folosește OAuth 2.1 și OpenID Connect, nu scheme de autentificare proprii
- Nu folosi fluxurile Implicit și Resource Owner Password Credentials
- Stochează parolele cu Argon2id sau bcrypt, niciodată în clar
- Oferă MFA și passkeys (WebAuthn) pentru conturile utilizatorilor
- Returnează mesaje generice la eșecul autentificării, fără enumerare de conturi
- Folosește token-uri de resetare a parolei unice, aleatorii și cu expirare scurtă
- Tratează cheile API ca secrete: scope limitat, rotație și revocare