Allowed callback URLs: exact-match rules, wildcards, and org placeholders

TL;DR: Auth0 rejects any redirecturi that does not match the allowlist exactly. Trailing slashes, ports, and casing cause most failures; wildcards only work at the subdomain level. The redirecturi in the authorize request must match an entry character for character: scheme, host, port, path. Never leave YOUR_HOST entries on a production app.

Callback URL rules

The exact-match rule

Allowed Callback URLs is a strict allowlist. The redirect_uri in the authorize request must match an entry character for character: scheme, host, port, path. Common killers:

• https://app.example.com/callback vs https://app.example.com/callback/ (trailing slash)
• the service URL for that host and port vs the service URL for that host and port (port drift in dev)
• https://App.example.com/x vs https://app.example.com/x (host casing)
• query strings on the redirect_uri (register without them; Auth0 strips and re-adds its own params)

Comma-separate multiple URLs for dev/staging/prod. Never leave YOUR_HOST entries on a production app.

Wildcards

https://*.example.com is allowed at the subdomain level. Path wildcards are not a thing. Auth0's own guidance: avoid wildcards in production callbacks; they widen the redirect surface. For multi-tenant B2B, prefer the {organization_name} placeholder (https://{organization_name}.example.com) on domains you fully control.

The three URL fields

• Allowed Callback URLs: where Auth0 sends users after login (with the code).
• Allowed Logout URLs: where Auth0 may send users after /v2/logout via returnTo.
• Allowed Web Origins: origins allowed to make CORS/iframe calls to Auth0 (silent auth, passwordless). Query strings and hashes are ignored here.

Native apps

Custom schemes like [your scheme]://callback are registered the same way, but prefer claimed HTTPS URIs (App Links / Universal Links) where the platform allows; custom schemes are subject to client impersonation.

Checklist

• Copy the redirect_uri from the failing authorize request (browser devtools) and diff it against the dashboard entry.
• One entry per environment; delete stale ones.

When to use this

• This covers exactly what the title says: Allowed callback URLs.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Allowed; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Allowed behavior.