// docs / baas security / auth0 hardening

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

Auth0 es una plataforma de identidad-como-servicio con una superficie enorme — aplicaciones, APIs (servidores de recursos), tenants, acciones, reglas (heredadas), conexiones y grants. La mala configuración de cualquiera de ellos es un bypass de autenticación. Esta lista de comprobación es una auditoría de 22 elementos en aplicaciones, listas de callback / logout, tokens y rotación de refresh, acciones personalizadas, RBAC, detección de anomalías y monitoreo continuo. Cada elemento es verificable en el panel de Auth0 en menos de 10 minutos.

Para la lista de comprobación equivalente en Clerk, consulta Lista de comprobación de seguridad de Clerk. Para el contexto sobre por qué las configuraciones erróneas a nivel de identidad son puntos ciegos de las herramientas de IA, consulta Por qué las herramientas de codificación con IA dejan huecos de seguridad.

Tipo de aplicación y tipos de grant

El tipo de aplicación y los tipos de grant habilitados son los ajustes de mayor impacto en Auth0. Equivocarse abre clases de ataque que ninguna cantidad de código de frontend cerrará.

Usa Tipo de Aplicación = Single Page Application para aplicaciones solo de navegador y Regular Web Application para aplicaciones renderizadas en servidor. El tipo equivocado permite los grants equivocados — p. ej., una Regular Web App con el grant SPA habilita el flujo Implicit sin PKCE, que filtra tokens vía fragmentos de URL.
Desactiva el tipo de grant Implicit en cada aplicación. Panel → Aplicación → Ajustes avanzados → Tipos de Grant → desmarca Implicit. El flujo Implicit devuelve tokens en fragmentos de URL, donde quedan registrados en el historial del navegador y la analítica. Usa Authorization Code con PKCE en su lugar.
Desactiva el grant Password a menos que tengas una necesidad documentada. El grant Resource Owner Password Credentials (ROPC) requiere que manejes las contraseñas de usuario tú mismo — derrotando casi todo lo que compraste con Auth0. Desactívalo a menos que integres un sistema heredado.
Habilita Authorization Code con PKCE en cada cliente público. Panel → Ajustes avanzados → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = habilitado. PKCE es requerido para aplicaciones móviles y SPAs para prevenir la interceptación de código.

Listas de URLs de callback y logout

Las redirecciones abiertas en la ruta de callback de OAuth son una primitiva de robo de tokens. La lista de permitidos de Auth0 es tu única defensa.

Pon Allowed Callback URLs a tu ruta de callback de producción exacta — sin comodines. https://yourapp.com/callback, no https://yourapp.com/*. Los callbacks con comodín permiten a atacantes redirigir tokens a subrutas arbitrarias de tu dominio.
Pon Allowed Logout URLs a una lista finita. Misma regla: solo URLs explícitas. Una redirección de logout abierta permite a atacantes crear páginas de phishing que se parezcan a tu estado post-logout.
Pon Allowed Web Origins solo a tu origen de producción. Se usa para autenticación silenciosa (renovación de token vía iframe oculto). Un origen con comodín permite a páginas de atacantes hacer autenticación silenciosa contra tu tenant.
Pon Allowed CORS origins para los endpoints de API, no para la aplicación. Ajustes del Tenant → Avanzado → Allowed CORS origins. El predeterminado es vacío (restringido); añade solo orígenes explícitos que controles.

Tokens y rotación de refresh

La vida del token, la rotación de refresh y el algoritmo de firma deciden el radio de impacto de cualquier fuga de token.

Habilita la Rotación de Refresh Token. Aplicación → Ajustes de Refresh Token → Rotación. Cada refresh emite un nuevo refresh token e invalida el antiguo. Combinado con caducidad absoluta, esto contiene el robo de tokens.
Pon Refresh Token Reuse Interval a 0 (o lo más bajo que tu tolerancia de replay permita). El intervalo de reuso permite usar un token dos veces en la misma ventana — apágalo a menos que tengas una razón específica para mantenerlo.
Pon Absolute Refresh Token Expiry a 14-30 días, no a infinito. Aplicación → Caducidad de Refresh Token → Caducidad Absoluta. Auth0 por defecto solo Inactividad, lo que significa que una sesión inactiva puede persistir años.
Pon JWT Signature Algorithm en RS256. Aplicación → Avanzado → OAuth → JsonWebToken Signature Algorithm. RS256 usa firma asimétrica, por lo que el cliente no puede falsificar tokens. Nunca uses HS256 para aplicaciones de cara al cliente.
Verifica los claims aud e iss en cada JWT que reciba tu API. Usa el SDK oficial de Auth0 en el lado del servidor — los verifica automáticamente. El parseo manual de JWT suele saltarse la validación de audiencia, lo que es un bypass de autenticación.

Acciones y código personalizado

Las Acciones de Auth0 (y las Reglas heredadas) se ejecutan en el servidor en el inicio de sesión y otros eventos del ciclo de vida. Tienen acceso a todo el contexto de la solicitud. El código inseguro aquí es una vulnerabilidad de todo el tenant.

Nunca registres event.user o event.transaction como objeto completo. Contienen direcciones de correo, IPs y otro PII. Usa registro a nivel de campo solo, y registra solo lo que necesites.
Usa el almacén de secretos para cualquier clave de API o URL de webhook. Acciones → Editar → Secretos. Nunca incrustes una clave de API como literal de cadena en el código de acción — el código es visible para cualquiera con acceso de editor de Acción en el tenant.
Valida las entradas antes de persistirlas como user_metadata o app_metadata. Una acción de autoservicio que escribe event.body.name en user.user_metadata.display_name es un vector de XSS persistente si tu frontend renderiza ese campo sin escape.

RBAC y servidores de recursos

Si usas Auth0 RBAC, el mapeo rol-a-permiso es tu capa de autorización. Equivócate y cualquier usuario autenticado puede llegar a endpoints de administración.

Define los Servidores de Recursos (APIs) explícitamente en el panel de Auth0, no sobre la marcha. Cada API tiene un identificador (la audience), scopes y ajustes de firma. Sin una API registrada, todos los tokens se emiten para la implícita "Auth0 Management API" — audiencia equivocada.
Configura Permisos por API y requiérelos en tu código con el claim scope. No compruebes membresía de rol en la lógica de tu aplicación; comprueba scopes en el token de acceso. Los scopes son el mecanismo de autorización nativo de OAuth.
Prueba que un usuario autenticado sin el rol / scope requerido no pueda llegar a endpoints privilegiados. Inicia sesión como usuario normal, intenta llamar a POST /api/admin/users/delete. La respuesta debe ser 403.

Detección de anomalías y logs del tenant

Auth0 emite eventos de alta señal. Configúralos para que alerten a tu equipo, no solo se queden en un búfer de logs.

Habilita Attack Protection: Detección de Bots, Fuerza Bruta, Limitación de IPs sospechosas. Panel → Seguridad → Attack Protection. Cada uno está apagado por defecto en planes gratuitos; actívalos todos para producción.
Envía los logs del tenant a un SIEM o a los logs de tu aplicación. Panel → Monitoreo → Streams. Auth0 retiene los logs durante 30 días en la mayoría de planes; la retención a largo plazo requiere un stream a tu propio sistema.
Alerta sobre picos de fcoa (autenticación entre orígenes fallida) y fp (inicio de sesión fallido). Una ráfaga de estos en una ventana corta es credential stuffing. Envíalo a tu canal de guardia.

Próximos pasos

Ejecuta un escaneo de FixVibe contra tu URL de producción — la verificación baas.clerk-auth0 marca secretos de cliente de Auth0 incrustados en JavaScript y otras clases de exposición de proveedor de identidad. Para el equivalente en Clerk, consulta Lista de comprobación de seguridad de Clerk. Para la vista general en proveedores BaaS, lee Escáner de configuraciones erróneas de BaaS.