// docs / baas security / auth0 hardening

Auth0 security checklist: 22 items

Auth0 is an identity-as-a-service platform with an enormous surface — applications, APIs (resource servers), tenants, actions, rules (legacy), connections, and grants. Misconfiguration of any one of them is an auth bypass. This checklist is a 22-item audit across applications, callback / logout allowlists, tokens and refresh rotation, custom actions, RBAC, anomaly detection, and ongoing monitoring. Each item is verifiable in the Auth0 Dashboard in under 10 minutes.

For the equivalent checklist on Clerk, see <clerkArticle>Clerk security checklist</clerkArticle>. For background on why identity-layer misconfigurations are AI-tool blind spots, see <aiGaps>Why AI coding tools leave security gaps</aiGaps>.

Application type and grant types

The application type and the enabled grant types are the highest-impact settings in Auth0. Getting them wrong opens classes of attack that no amount of frontend code will close.

Use Application Type = Single Page Application for browser-only apps and Regular Web Application for server-rendered apps. The wrong type allows the wrong grant types — e.g., a Regular Web App with the SPA grant enables PKCE-less Implicit flow, which leaks tokens via URL fragments.
Disable the Implicit grant type on every application. Dashboard → Application → Advanced Settings → Grant Types → uncheck Implicit. Implicit flow returns tokens in URL fragments, where they are logged in browser history and analytics. Use Authorization Code with PKCE instead.
Disable Password grant unless you have a documented need. Resource Owner Password Credentials (ROPC) grant requires you to handle user passwords yourself — defeating most of what you bought Auth0 for. Disable it unless integrating a legacy system.
Enable Authorization Code with PKCE on every public client. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = enabled. PKCE is required for mobile apps and SPAs to prevent code interception.

Callback and logout URL allowlists

Open redirects on the OAuth callback path are a token-theft primitive. Auth0's allowlist is your only defense.

Set Allowed Callback URLs to your exact production callback path — no wildcards. <code>https://yourapp.com/callback</code>, not <code>https://yourapp.com/*</code>. Wildcard callbacks let attackers redirect tokens to arbitrary subpaths on your domain.
Set Allowed Logout URLs to a finite list. Same rule: explicit URLs only. An open logout redirect lets attackers craft phishing pages that look like your post-logout state.
Set Allowed Web Origins to your production origin only. Used for silent authentication (token renewal via hidden iframe). A wildcard origin lets attacker pages perform silent auth against your tenant.
Set Allowed CORS origins for the API endpoints, not the application. Tenant Settings → Advanced → Allowed CORS origins. Default is empty (restricted); only add explicit origins you control.

Tokens and refresh rotation

Token lifetime, refresh rotation, and signing algorithm decide the blast radius of any token leak.

Enable Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Each refresh issues a new refresh token and invalidates the old one. Combined with absolute expiry, this contains token theft.
Set Refresh Token Reuse Interval to 0 (or as low as your replay tolerance allows). The reuse interval lets a token be used twice in the same window — turn it off unless you have a specific reason to keep it.
Set Absolute Refresh Token Expiry to 14-30 days, not infinity. Application → Refresh Token Expiration → Absolute Expiration. Auth0 defaults to Inactivity-only, which means an idle session can persist for years.
Set JWT Signature Algorithm to RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 uses asymmetric signing so the client cannot forge tokens. Never use HS256 for client-facing applications.
Verify <code>aud</code> and <code>iss</code> claims on every JWT your API receives. Use the official Auth0 SDK on the server side — it verifies these automatically. Hand-rolled JWT parsing usually skips audience validation, which is an auth bypass.

Actions and custom code

Auth0 Actions (and legacy Rules) run server-side at login and other lifecycle events. They have access to the entire request context. Insecure code here is a tenant-wide vulnerability.

Never log <code>event.user</code> or <code>event.transaction</code> as a whole object. These contain email addresses, IP addresses, and other PII. Use field-level logging only, and only log what you need.
Use the secrets store for any API key or webhook URL. Actions → Edit → Secrets. Never inline an API key as a string literal in action code — the code is visible to anyone with Action editor access on the tenant.
Validate inputs before persisting them as user_metadata or app_metadata. A self-service action that writes <code>event.body.name</code> to <code>user.user_metadata.display_name</code> is a stored-XSS vector if your frontend renders that field without escaping.

RBAC and resource servers

If you use Auth0 RBAC, the role-to-permission mapping is your authorization layer. Get it wrong and any authenticated user can hit admin endpoints.

Define Resource Servers (APIs) explicitly in the Auth0 Dashboard, not on the fly. Each API has an identifier (the <code>audience</code>), scopes, and signing settings. Without a registered API, all tokens are issued for the implicit "Auth0 Management API" — wrong audience.
Configure Permissions per API and require them in your code with the <code>scope</code> claim. Don't check role membership in your application logic; check scopes in the access token. Scopes are the OAuth-native authorization mechanism.
Test that an authenticated user without the required role / scope cannot hit privileged endpoints. Sign in as a normal user, try to call <code>POST /api/admin/users/delete</code>. Response must be <code>403</code>.

Anomaly detection and tenant logs

Auth0 emits high-signal events. Set them up to alert your team, not just sit in a log buffer.

Enable Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Each is off by default on free tiers; turn them all on for production.
Stream tenant logs to a SIEM or your application logs. Dashboard → Monitoring → Streams. Auth0 retains logs for 30 days on most plans; long-term retention requires a stream into your own system.
Alert on <code>fcoa</code> (failed cross-origin auth) and <code>fp</code> (failed login) spikes. A burst of these in a short window is credential stuffing. Route to your on-call channel.

Next steps

Run a FixVibe scan against your production URL — the <code>baas.clerk-auth0</code> check flags Auth0 client secrets bundled in JavaScript and other identity-provider exposure classes. For the equivalent on Clerk, see <clerkArticle>Clerk security checklist</clerkArticle>. For the umbrella view across BaaS providers, read <baasScannerArticle>BaaS misconfiguration scanner</baasScannerArticle>.