// docs / baas security / auth0 hardening

Lista de comprobación de seguranza de Auth0: 22 elementos

Auth0 é unha plataforma de identidade-como-servizo cunha superficie enorme — aplicacións, APIs (servidores de recursos), tenants, accións, regras (herdadas), conexións e concesións. A configuración incorrecta de calquera delas é un bypass de autenticación. Esta lista é unha auditoría de 22 elementos en aplicacións, listas de callback / logout, tokens e rotación de refresh, accións personalizadas, RBAC, detección de anomalías e monitorización continua. Cada elemento é verificábel no Panel de Auth0 en menos de 10 minutos.

Para a lista equivalente en Clerk, mira Lista de comprobación de seguranza de Clerk. Para o fondo sobre por que as configuracións incorrectas a nivel de identidade son puntos cegos das ferramentas de IA, mira Por que as ferramentas de codificación con IA deixan fendas de seguranza.

Tipo de aplicación e tipos de concesión

O tipo de aplicación e os tipos de concesión activados son a configuración de maior impacto en Auth0. Errar con eles abre clases de ataque que ningunha cantidade de código de frontend pechará.

Usa Application Type = Single Page Application para aplicacións só de navegador e Regular Web Application para aplicacións renderizadas no servidor. O tipo incorrecto permite os tipos de concesión incorrectos — por exemplo, unha Regular Web App coa concesión SPA habilita o fluxo Implicit sen PKCE, que filtra tokens vía fragmentos de URL.
Desactiva o tipo de concesión Implicit en cada aplicación. Panel → Aplicación → Configuración avanzada → Tipos de concesión → desmarca Implicit. O fluxo Implicit devolve tokens en fragmentos de URL, onde se rexistran no historial do navegador e en analítica. Usa Authorization Code con PKCE no seu lugar.
Desactiva a concesión Password a menos que teñas unha necesidade documentada. A concesión Resource Owner Password Credentials (ROPC) require que ti mesmo manexes os contrasinais dos usuarios — derrotando a maioría do que compraches Auth0 para. Desactívaa a menos que estes a integrar un sistema herdado.
Activa Authorization Code con PKCE en cada cliente público. Panel → Configuración avanzada → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = activado. PKCE é necesario para aplicacións móbiles e SPAs para previr a intercepción de código.

Listas de URLs de callback e logout

As redireccións abertas no camiño de callback de OAuth son unha primitiva de roubo de tokens. A lista permitida de Auth0 é a túa única defensa.

Pon Allowed Callback URLs ao teu camiño exacto de callback de produción — sen comodíns. https://yourapp.com/callback, non https://yourapp.com/*. Os callbacks con comodín permiten que os atacantes redirixan tokens a subcamiños arbitrarios do teu dominio.
Pon Allowed Logout URLs a unha lista finita. Mesma regra: só URLs explícitos. Unha redirección de logout aberta permite que os atacantes elaboren páxinas de phishing que parecen o teu estado post-logout.
Pon Allowed Web Origins só á túa orixe de produción. Usada para autenticación silenciosa (renovación de token vía iframe oculto). Unha orixe con comodín permite que páxinas atacantes realicen autenticación silenciosa contra o teu tenant.
Pon Allowed CORS origins para os endpoints API, non para a aplicación. Configuración do Tenant → Avanzado → Allowed CORS origins. O predeterminado é baleiro (restrinxido); engade só orixes explícitas que controles.

Tokens e rotación de refresh

A duración do token, a rotación de refresh e o algoritmo de sinatura deciden o radio de explosión de calquera fuga de token.

Activa a Rotación de Refresh Token. Aplicación → Configuración de Refresh Token → Rotación. Cada refresh emite un novo refresh token e inválida o antigo. Combinado con expiración absoluta, isto contén o roubo de tokens.
Pon o intervalo de reutilización de Refresh Token a 0 (ou tan baixo como a túa tolerancia de replay permita). O intervalo de reutilización permite que un token se use dúas veces na mesma xanela — apágao a menos que teñas un motivo específico para mantelo.
Pon a Expiración Absoluta de Refresh Token a 14-30 días, non a infinito. Aplicación → Expiración de Refresh Token → Expiración Absoluta. Auth0 ten por defecto só Inactividade, o que significa que unha sesión inactiva pode persistir durante anos.
Pon JWT Signature Algorithm a RS256. Aplicación → Avanzado → OAuth → JsonWebToken Signature Algorithm. RS256 usa sinatura asimétrica de modo que o cliente non pode falsificar tokens. Nunca uses HS256 para aplicacións orientadas a cliente.
Verifica os claims aud e iss en cada JWT que reciba a túa API. Usa o SDK oficial de Auth0 no servidor — verifícaos automaticamente. A análise JWT feita a man adoita saltarse a validación de audiencia, o que é un bypass de autenticación.

Accións e código personalizado

As Accións de Auth0 (e as Regras herdadas) executan no servidor durante o login e outros eventos do ciclo de vida. Teñen acceso a todo o contexto da solicitude. Código inseguro aquí é unha vulnerabilidade en todo o tenant.

Nunca rexistres event.user ou event.transaction como obxecto completo. Estes conteñen enderezos de correo electrónico, IPs e outras PII. Usa só rexistro a nivel de campo e rexistra só o que necesites.
Usa o almacén de segredos para calquera clave API ou URL de webhook. Accións → Editar → Segredos. Nunca incrustes unha clave API como literal de cadea no código da acción — o código é visible a calquera con acceso de editor de accións no tenant.
Valida as entradas antes de persistilas como user_metadata ou app_metadata. Unha acción de autoservizo que escribe event.body.name en user.user_metadata.display_name é un vector de XSS almacenado se o teu frontend renderiza ese campo sen escapalo.

RBAC e servidores de recursos

Se usas RBAC de Auth0, o mapeo de rol a permiso é a túa capa de autorización. Erra con el e calquera usuario autenticado pode atacar endpoints de administración.

Define os Servidores de Recursos (APIs) explicitamente no Panel de Auth0, non sobre a marcha. Cada API ten un identificador (a audience), ámbitos e configuración de sinatura. Sen unha API rexistrada, todos os tokens emítense para a implícita "Auth0 Management API" — audiencia incorrecta.
Configura Permisos por API e requíreos no teu código co claim scope. Non comprobes pertenza de rol na lóxica da túa aplicación; comproba ámbitos no token de acceso. Os ámbitos son o mecanismo de autorización nativo de OAuth.
Proba que un usuario autenticado sen o rol / ámbito necesario non pode atacar endpoints privilexiados. Inicia sesión como usuario normal, tenta chamar POST /api/admin/users/delete. A resposta debe ser 403.

Detección de anomalías e rexistros do tenant

Auth0 emite eventos de alta sinal. Configúraos para alertar ao teu equipo, non só para que se senten nun búfer de rexistro.

Activa Protección Ante Ataques: Bot Detection, Brute Force, Suspicious IP Throttling. Panel → Seguranza → Protección Ante Ataques. Cada un está desactivado por defecto nos plans gratuítos; actívaos todos para produción.
Transmite os rexistros do tenant a un SIEM ou aos rexistros da túa aplicación. Panel → Monitorización → Streams. Auth0 mantén os rexistros durante 30 días na maioría dos plans; a retención a longo prazo require un stream ao teu propio sistema.
Alerta sobre picos de fcoa (autenticación entre orixes fallida) e fp (inicio de sesión fallido). Unha rajada destes nunha xanela curta é credential stuffing. Encamíñao á túa canle de garda.

Próximos pasos

Executa un escaneo de FixVibe contra o teu URL de produción — a comprobación baas.clerk-auth0 sinala segredos de cliente de Auth0 incluídos no JavaScript e outras clases de exposición de provedores de identidade. Para o equivalente en Clerk, mira Lista de comprobación de seguranza de Clerk. Para a visión global de provedores BaaS, le Escáner de configuración incorrecta de BaaS.