// docs / baas security / auth0 hardening

Llista de comprovació de seguretat d'Auth0: 22 punts

Auth0 és una plataforma d'identitat com a servei amb una superfície enorme — aplicacions, APIs (servidors de recursos), tenants, accions, regles (heretades), connexions i grants. Una configuració errònia de qualsevol d'ells és un bypass d'autenticació. Aquesta llista de comprovació és una auditoria de 22 punts entre aplicacions, llistes de callback / logout, tokens i rotació de refresh, accions personalitzades, RBAC, detecció d'anomalies i monitoratge continuat. Cada punt és verificable al panell d'Auth0 en menys de 10 minuts.

Per a la llista de comprovació equivalent a Clerk, consulta Llista de comprovació de seguretat de Clerk. Per saber per què les configuracions errònies de la capa d'identitat són punts cecs de les eines d'IA, consulta Per què les eines de codificació amb IA deixen mancances de seguretat.

Tipus d'aplicació i tipus de grant

El tipus d'aplicació i els tipus de grant habilitats són els paràmetres de més impacte d'Auth0. Equivocar-los obre classes d'atac que cap quantitat de codi de frontend tancarà.

Fes servir Application Type = Single Page Application per a aplicacions només-navegador i Regular Web Application per a aplicacions renderitzades al servidor. El tipus incorrecte permet els tipus de grant incorrectes — p. ex., una Regular Web App amb el grant SPA habilita el flux Implicit sense PKCE, que filtra tokens via fragments d'URL.
Deshabilita el tipus de grant Implicit a cada aplicació. Panell → Application → Advanced Settings → Grant Types → desmarca Implicit. El flux Implicit retorna tokens en fragments d'URL, on queden registrats a l'historial del navegador i les analítiques. Fes servir Authorization Code amb PKCE.
Deshabilita el grant Password tret que tinguis una necessitat documentada. El grant Resource Owner Password Credentials (ROPC) et requereix manejar les contrasenyes dels usuaris tu mateix — anul·la la majoria de coses pel que has comprat Auth0. Deshabilita'l tret que integris un sistema heretat.
Habilita Authorization Code amb PKCE a cada client públic. Panell → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = enabled. PKCE és necessari per a aplicacions mòbils i SPAs per evitar la intercepció del codi.

Llistes d'autorització d'URLs de callback i logout

Les redireccions obertes a la ruta de callback OAuth són una primitiva de robatori de token. La llista d'autorització d'Auth0 és la teva única defensa.

Estableix Allowed Callback URLs a la teva ruta de callback de producció exacta — sense comodins. https://yourapp.com/callback, no https://yourapp.com/*. Els callbacks amb comodí permeten als atacants redirigir tokens a subrutes arbitràries del teu domini.
Estableix Allowed Logout URLs a una llista finita. La mateixa regla: només URLs explícites. Una redirecció oberta de logout permet als atacants crear pàgines de phishing que semblen el teu estat post-logout.
Estableix Allowed Web Origins només al teu origen de producció. Es fa servir per a l'autenticació silenciosa (renovació de tokens via iframe ocult). Un origen amb comodí permet a pàgines d'atacant fer autenticació silenciosa contra el teu tenant.
Estableix Allowed CORS origins per als endpoints de l'API, no per a l'aplicació. Tenant Settings → Advanced → Allowed CORS origins. El valor per defecte és buit (restringit); afegeix només orígens explícits que controlis.

Tokens i rotació de refresh

La vida útil del token, la rotació de refresh i l'algoritme de signatura decideixen el radi d'explosió de qualsevol fuita de token.

Habilita Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Cada refresh emet un nou refresh token i invalida l'antic. Combinat amb caducitat absoluta, això conté el robatori de tokens.
Estableix Refresh Token Reuse Interval a 0 (o tan baix com permeti la teva tolerància a replays). L'interval de reutilització permet que un token es faci servir dues vegades a la mateixa finestra — desactiva'l tret que tinguis una raó específica per mantenir-lo.
Estableix Absolute Refresh Token Expiry a 14-30 dies, no a infinit. Application → Refresh Token Expiration → Absolute Expiration. Auth0 per defecte només té Inactivity, fet que vol dir que una sessió inactiva pot persistir durant anys.
Estableix JWT Signature Algorithm a RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 fa servir signatura asimètrica de manera que el client no pot falsificar tokens. No facis servir mai HS256 per a aplicacions de cara al client.
Verifica els claims aud i iss a cada JWT que rebi la teva API. Fes servir el SDK oficial d'Auth0 al costat servidor — els verifica automàticament. El parsing manual de JWT sol saltar-se la validació d'audience, fet que és un bypass d'autenticació.

Accions i codi personalitzat

Les Auth0 Actions (i les Rules heretades) s'executen al servidor a l'inici de sessió i altres esdeveniments del cicle de vida. Tenen accés a tot el context de la petició. Codi insegur aquí és una vulnerabilitat de tot el tenant.

No registris mai event.user ni event.transaction com a objecte sencer. Contenen adreces d'email, adreces IP i altres PII. Fes servir només registre a nivell de camp, i registra només el que necessitis.
Fes servir el magatzem de secrets per a qualsevol clau API o URL de webhook. Actions → Edit → Secrets. No facis mai inline d'una clau API com a literal de cadena al codi d'acció — el codi és visible per a qualsevol amb accés a l'editor d'Actions al tenant.
Valida les entrades abans de persistir-les com a user_metadata o app_metadata. Una acció de self-service que escriu event.body.name a user.user_metadata.display_name és un vector XSS persistent si el teu frontend renderitza aquest camp sense escapar.

RBAC i servidors de recursos

Si fas servir Auth0 RBAC, el mapatge rol-a-permís és la teva capa d'autorització. Equivoca't i qualsevol usuari autenticat pot accedir a endpoints d'administració.

Defineix Resource Servers (APIs) explícitament al panell d'Auth0, no al vol. Cada API té un identificador (l<code>audience</code>), scopes i paràmetres de signatura. Sense una API registrada, tots els tokens semeten per a la implícita "Auth0 Management API" — audience incorrecte.
Configura Permissions per API i requereix-los al codi amb el claim scope. No comprovis la pertinença a rol a la lògica de l'aplicació; comprova scopes al token d'accés. Els scopes són el mecanisme d'autorització natiu d'OAuth.
Prova que un usuari autenticat sense el rol / scope requerit no pot accedir a endpoints privilegiats. Inicia sessió com a usuari normal, intenta cridar POST /api/admin/users/delete. La resposta ha de ser 403.

Detecció d'anomalies i logs de tenant

Auth0 emet esdeveniments d'alt senyal. Configura'ls perquè alertin el teu equip, no només seguin en un buffer de logs.

Habilita Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Panell → Security → Attack Protection. Cadascun està desactivat per defecte als plans gratuïts; activa'ls tots per a producció.
Envia els logs de tenant a un SIEM o als logs de la teva aplicació. Panell → Monitoring → Streams. Auth0 reté els logs durant 30 dies a la majoria de plans; la retenció a llarg termini requereix un stream al teu propi sistema.
Alerta sobre pics de fcoa (failed cross-origin auth) i fp (failed login). Un esclat d'aquests en una finestra curta és credential stuffing. Encamina'ls al teu canal de guàrdia.

Següents passos

Executa un escaneig de FixVibe contra el teu URL de producció — la comprovació baas.clerk-auth0 marca client secrets d'Auth0 inclosos a JavaScript i altres classes d'exposició de proveïdor d'identitat. Per a l'equivalent a Clerk, consulta Llista de comprovació de seguretat de Clerk. Per a la vista general entre proveïdors BaaS, llegeix Escàner de configuracions errònies de BaaS.