// docs / baas security / auth0 hardening
Lista di cuntrollu di sicurezza Auth0: 22 elementi
Auth0 hè una piattaforma di identità-cum'è-serviziu cù una superficia enorme — appiendice, API (resource server), tenant, azzione, regule (legacy), cunnessione, è cuncessione. U sbagliu di cunfigurazione di qualunque ne hè un bypass di auth. Sta lista di cuntrollu hè un audit di 22 elementi trà appiendice, liste d'auturizazione callback / logout, token è rotazione di refresh, azzione persunalizate, RBAC, rilevazione d'anomalie, è monitoraghju cuntinuu. Ogni elementu hè verificabile in u Dashboard Auth0 in menu di 10 minuti.
Per a lista di cuntrollu equivalente nantu à Clerk, vedi Lista di cuntrollu di sicurezza Clerk. Per u sfondu nantu à perchè i sbagli di cunfigurazione di u stratu d'identità sò punti cechi di l'attrezzi IA, vedi Perchè l'attrezzi di codifica IA lascianu falle di sicurezza.
Tippu d'appiendica è tippi di cuncessione
U tippu d'appiendica è i tippi di cuncessione attivati sò i paràmetri à più altu impattu in Auth0. Sbagliare ne apre classi d'attaccu chì nesuna quantità di codice frontend chjuderà.
- Adopra Application Type = Single Page Application per app solu navigatore è Regular Web Application per app rese latu servitore. U tippu sbagliatu permette i tippi di cuncessione sbagliati — per esempiu, una Regular Web App cù a cuncessione SPA attiva u flussu Implicit senza PKCE, chì perde token via fragmenti di URL.
- Disattiva u tippu di cuncessione Implicit in ogni appiendica. Dashboard → Application → Advanced Settings → Grant Types → smarca Implicit. U flussu Implicit torna token in fragmenti di URL, duve sò registrati in a storia di u navigatore è in l'analytics. Adopra Authorization Code cù PKCE invece.
- Disattiva a cuncessione Password salvu chì ùn hai una necessità ducumentata. A cuncessione Resource Owner Password Credentials (ROPC) richiede di trattà tù i password d'utente — sconfendu a maiò parte di ciò chì hai compru Auth0 per. Disattivala salvu chì integri un sistema legacy.
- Attiva Authorization Code cù PKCE nantu à ogni cliente publicu. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = attivatu. PKCE hè richiestu per app mobili è SPA per prevene l'intercezione di codice.
Liste d'auturizazione URL callback è logout
I redirect aperti nantu à u percorsu OAuth callback sò una primitiva di furtu di token. A lista d'auturizazione Auth0 hè a to sola difesa.
- Mette Allowed Callback URLs à u to percorsu di callback di produzzione esattu — nisun wildcard.
https://yourapp.com/callback, miccahttps://yourapp.com/*. I callback wildcard lascianu l'attaccanti redirige token à sotto-percorsi arbitrarii nantu à u to duminiu. - Mette Allowed Logout URLs à una lista finita. Listessa regula: URL espliciti solu. Un redirect di logout apertu lascia l'attaccanti creà pagine di phishing chì paranu u to statu post-logout.
- Mette Allowed Web Origins à a to urigine di produzzione solu. Aduprata per l'autenticazione silenziosa (rinnovazione di token via iframe nascostu). Una urigine wildcard lascia pagine d'attaccante eseguì auth silenzioso contru à u to tenant.
- Mette Allowed CORS origins per l'endpoint API, micca per l'appiendica. Tenant Settings → Advanced → Allowed CORS origins. U difettu hè viotu (ristrettu); aghjusta solu urigini esplicite chì cuntrolli.
Token è rotazione di refresh
A vita di u token, a rotazione di refresh, è l'algoritmu di firma decidenu u raggiu di splusione di qualunque perdita di token.
- Attiva a rotazione di Refresh Token. Application → Refresh Token Settings → Rotation. Ogni refresh emette un novu refresh token è invalideghja u vechju. Cumbinatu cù scadenza assoluta, questu cuntene u furtu di token.
- Mette Refresh Token Reuse Interval à 0 (o quantu più bassu cumu permette a to tolleranza di replay). L'intervallu di riusu lascia un token esse adupratu duie volte in listessa finestra — spignila salvu chì hai una ragione specifica per tene la.
- Mette Absolute Refresh Token Expiry à 14-30 ghjorni, micca infinitu. Application → Refresh Token Expiration → Absolute Expiration. Auth0 hà per difettu Inactivity-solu, chì significheghja chì una sessione inattiva pò persiste per anni.
- Mette JWT Signature Algorithm à RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 usa firma asimmetrica cusì u cliente ùn pò micca fà token falsi. Mai aduprà HS256 per appiendice rivolte à u cliente.
- Verifica i claim
audèissnantu à ogni JWT chì a to API riceve. Adopra u SDK Auth0 ufficiale nantu à u latu servitore — i verifica automaticamente. U parsing JWT fattu à manu di solitu salta a validazione di audience, chì hè un bypass di auth.
Azzione è codice persunalizatu
L'Azzione Auth0 (è e regule legacy) girenu latu servitore à u login è altri eventi di ciclu di vita. Anu accessu à u cuntestu cumpletu di a richiesta. Codice insicuru quì hè una vulnerabilità trà tuttu u tenant.
- Mai loga
event.useroevent.transactioncum'è un ughjettu sanu. Quessi cuntenenu indirizzi email, indirizzi IP, è altre PII. Adopra logging à livellu di campu solu, è loga solu ciò chì hai bisognu. - Adopra u stoccu di secreti per qualunque chjave API o URL di webhook. Actions → Edit → Secrets. Mai inserisce una chjave API cum'è un littarale di stringa in u codice d'azzione — u codice hè visibile à chìunque cù accessu d'editore d'Azzione nantu à u tenant.
- Valideghja l'input prima di persistille cum'è user_metadata o app_metadata. Una azzione self-service chì scrive
event.body.nameinuser.user_metadata.display_namehè un vettore XSS stuccatu s'è u to frontend rende quellu campu senza escape.
RBAC è resource server
S'è usi RBAC Auth0, a mappa rolu-à-permessu hè u to stratu d'auturizazione. Sbagliala è qualunque utente autenticatu pò chjamà l'endpoint d'amministratore.
- Definisce i Resource Server (API) esplicitamente in u Dashboard Auth0, micca à u volu. Ogni API hà un identificatore (l<code>audience</code>), scope, è paràmetri di firma. Senza una API registrata, tutti i token sò emessi per limplicita "Auth0 Management API" — audience sbagliata.
- Cunfigureghja i Permessi per API è richiedili in u to codice cù u claim
scope. Ùn cuntrullà l'appartenenza à u rolu in a logica di l'appiendica; cuntrolla scope in u token d'accessu. I scope sò u meccanismu d'auturizazione nativu OAuth. - Pruva chì un utente autenticatu senza u rolu / scope richiestu ùn pò micca chjamà l'endpoint privilegiati. Iscriviti cum'è utente normale, prova à chjamà
POST /api/admin/users/delete. A risposta deve esse403.
Rilevazione d'anomalie è log di tenant
Auth0 emette eventi à altu signale. Cunfigurali per allertà a to squadra, micca solu starsi in un buffer di log.
- Attiva Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Ognunu hè spentu per difettu in i piani gratisi; attiveghjali tutti per a produzzione.
- Stremma i log di tenant à un SIEM o à i log di a to appiendica. Dashboard → Monitoring → Streams. Auth0 cunserva i log per 30 ghjorni in a maiò parte di i piani; a rittenzione à longu termine richiede un stream in u to propiu sistema.
- Allerta nantu à picchji di
fcoa(failed cross-origin auth) èfp(failed login). Una scarica di quessi in una finestra corta hè credential stuffing. Instradeghja à u to canale di reperibilità.
Prussimi passi
Lampa una scansione FixVibe contru à u to URL di produzzione — u check baas.clerk-auth0 sgnala i secreti di cliente Auth0 impacchittati in JavaScript è altre classi d'esposizione di fornitore d'identità. Per l'equivalente nantu à Clerk, vedi Lista di cuntrollu di sicurezza Clerk. Per a vista d'imbrelli trà i fornitori BaaS, leghji Scanner di sbagli di cunfigurazione BaaS.