// docs / baas security / auth0 hardening

Lista de verificare pentru securitate Auth0: 22 de elemente

Auth0 este o platformă de identitate-ca-serviciu cu o suprafață enormă — aplicații, API-uri (resource servers), tenanți, acțiuni, reguli (legacy), conexiuni și grant-uri. Configurarea greșită a oricăruia este un bypass de autentificare. Această listă de verificare este un audit cu 22 de elemente pe aplicații, allowlist-uri pentru callback / logout, token-uri și rotația refresh-token, acțiuni personalizate, RBAC, detectarea anomaliilor și monitorizarea continuă. Fiecare element este verificabil în Auth0 Dashboard în mai puțin de 10 minute.

Pentru lista de verificare echivalentă pe Clerk, vezi Lista de verificare pentru securitate Clerk. Pentru context despre de ce configurările greșite la stratul de identitate sunt puncte oarbe ale instrumentelor AI, vezi De ce instrumentele de codare AI lasă lacune de securitate.

Tipul aplicației și tipurile de grant

Tipul aplicației și tipurile de grant activate sunt setările cu cel mai mare impact din Auth0. Greșindu-le, deschide clase de atac pe care niciun cod frontend nu le va închide.

Folosește Application Type = Single Page Application pentru aplicații doar-browser și Regular Web Application pentru aplicații cu server-rendering. Tipul greșit permite tipurile de grant greșite — de exemplu, un Regular Web App cu grant-ul SPA activează flow-ul Implicit fără PKCE, care scurge token-uri prin fragmentele de URL.
Dezactivează tipul de grant Implicit pe fiecare aplicație. Dashboard → Application → Advanced Settings → Grant Types → debifează Implicit. Flow-ul Implicit returnează token-uri în fragmentele URL-ului, unde sunt logate în istoricul browser-ului și analytics. Folosește Authorization Code cu PKCE în schimb.
Dezactivează grant-ul Password decât dacă ai o nevoie documentată. Grant-ul Resource Owner Password Credentials (ROPC) îți cere să gestionezi singur parolele utilizatorilor — învingând majoritatea motivelor pentru care ai cumpărat Auth0. Dezactivează-l decât dacă integrezi un sistem legacy.
Activează Authorization Code cu PKCE pe fiecare client public. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = activat. PKCE este obligatoriu pentru aplicațiile mobile și SPAs pentru a preveni interceptarea codului.

Allowlist-uri pentru callback și logout URL

Redirect-urile deschise pe calea callback-ului OAuth sunt o primitivă de furt de token. Allowlist-ul Auth0 este singura ta apărare.

Setează Allowed Callback URLs la calea ta exactă de callback de producție — fără wildcards. https://yourapp.com/callback, nu https://yourapp.com/*. Callback-urile cu wildcard le permit atacatorilor să redirecționeze token-urile către sub-căi arbitrare pe domeniul tău.
Setează Allowed Logout URLs la o listă finită. Aceeași regulă: doar URL-uri explicite. Un redirect deschis de logout le permite atacatorilor să creeze pagini de phishing care arată ca starea ta post-logout.
Setează Allowed Web Origins doar la originea ta de producție. Folosit pentru autentificare silențioasă (reînnoirea token-ului prin iframe ascuns). O origine cu wildcard le permite paginilor atacatorilor să efectueze autentificare silențioasă împotriva tenant-ului tău.
Setează Allowed CORS origins pentru endpoint-urile API, nu pentru aplicație. Tenant Settings → Advanced → Allowed CORS origins. Implicit este gol (restricționat); adaugă doar origini explicite pe care le controlezi.

Token-uri și rotație refresh

Durata token-ului, rotația refresh și algoritmul de semnare decid raza de impact a oricărei scurgeri de token.

Activează Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Fiecare refresh emite un nou refresh token și îl invalidează pe cel vechi. Combinat cu expirarea absolută, asta limitează furtul de token-uri.
Setează Refresh Token Reuse Interval la 0 (sau cât de mic permite toleranța ta de replay). Intervalul de reuse permite ca un token să fie folosit de două ori în aceeași fereastră — dezactivează-l decât dacă ai un motiv specific să-l păstrezi.
Setează Absolute Refresh Token Expiry la 14-30 zile, nu infinit. Application → Refresh Token Expiration → Absolute Expiration. Auth0 implicit este doar pe bază de Inactivitate, ceea ce înseamnă că o sesiune inactivă poate persista ani.
Setează JWT Signature Algorithm la RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 folosește semnare asimetrică, astfel încât clientul nu poate falsifica token-uri. Niciodată nu folosi HS256 pentru aplicații orientate spre client.
Verifică claim-urile aud și iss pe fiecare JWT pe care îl primește API-ul tău. Folosește SDK-ul oficial Auth0 pe server — le verifică automat. Parsarea JWT manuală sare de obicei peste validarea audience-ului, ceea ce este un bypass de autentificare.

Acțiuni și cod personalizat

Acțiunile Auth0 (și regulile legacy) rulează pe server la login și la alte evenimente de ciclu de viață. Au acces la întregul context al cererii. Codul nesigur aici este o vulnerabilitate la nivelul întregului tenant.

Niciodată nu loga event.user sau event.transaction ca obiect întreg. Acestea conțin adrese de email, adrese IP și alte PII. Folosește logging doar pe câmpuri și loghează doar ce ai nevoie.
Folosește store-ul de secrete pentru orice cheie API sau URL de webhook. Actions → Edit → Secrets. Niciodată să nu pui inline o cheie API ca literal de șir în codul acțiunii — codul este vizibil oricui are acces de editor de acțiuni pe tenant.
Validează inputurile înainte de a le persista ca user_metadata sau app_metadata. O acțiune self-service care scrie event.body.name la user.user_metadata.display_name este un vector XSS stocat dacă frontend-ul tău randează acel câmp fără escape.

RBAC și resource servers

Dacă folosești RBAC Auth0, maparea rol-la-permisiune este stratul tău de autorizare. Greșind-o, orice utilizator autentificat poate ajunge la endpoint-urile admin.

Definește explicit Resource Servers (API-uri) în Auth0 Dashboard, nu din mers. Fiecare API are un identificator (audience-ul), scope-uri și setări de semnare. Fără un API înregistrat, toate token-urile sunt emise pentru „Auth0 Management API" implicit — audience greșit.
Configurează permisiuni per API și cere-le în codul tău cu claim-ul scope. Nu verifica apartenența la rol în logica aplicației tale; verifică scope-urile în token-ul de acces. Scope-urile sunt mecanismul de autorizare nativ OAuth.
Testează că un utilizator autentificat fără rolul / scope-ul necesar nu poate ajunge la endpoint-urile privilegiate. Conectează-te ca utilizator normal, încearcă să apelezi POST /api/admin/users/delete. Răspunsul trebuie să fie 403.

Detectarea anomaliilor și log-urile de tenant

Auth0 emite evenimente cu semnal ridicat. Configurează-le să alerteze echipa ta, nu doar să stea într-un buffer de log.

Activează Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Fiecare este off implicit pe planurile gratuite; pornește-le pe toate pentru producție.
Streamuiește log-urile de tenant către un SIEM sau către log-urile aplicației tale. Dashboard → Monitoring → Streams. Auth0 reține log-urile timp de 30 de zile pe majoritatea planurilor; retenția pe termen lung necesită un stream în propriul tău sistem.
Alertă la spike-uri de fcoa (failed cross-origin auth) și fp (failed login). Un val al acestora într-o fereastră scurtă este credential stuffing. Rutează către canalul tău de on-call.

Pași următori

Rulează o scanare FixVibe împotriva URL-ului tău de producție — verificarea baas.clerk-auth0 semnalează secretele de client Auth0 livrate în JavaScript și alte clase de expunere ale furnizorului de identitate. Pentru echivalentul pe Clerk, vezi Lista de verificare pentru securitate Clerk. Pentru perspectiva generală asupra furnizorilor BaaS, citește Scaner de configurări greșite BaaS.