Wildcard subdomain + path callback URLs marked invalid after recent dashboard UI changes

Get Help
,
1

Hi,

I’m seeing what looks like a change in validation behaviour for Allowed Callback URLs involving wildcard subdomains and paths after the recent dashboard/UI updates to the URI input fields.

For example, these URLs are now marked as invalid in the dashboard UI:

  • https://*.example.com/app/account/
  • https://*.example.com/app/quotes/
  • https://*.example.com

The UI shows:

One or more callback URLs are invalid.

However, these callback URLs are still working as expected at runtime and authentication completes successfully using wildcard subdomains combined with fixed paths.

Non-wildcard equivalents validate successfully:

  • https://example.com/app/account/
  • https://example.com/app/quotes/
  • https://example.com

My understanding was that wildcard subdomains with fixed callback paths were supported as, for example:

https://*.example.com/auth/callback

Questions:

  • Has validation behaviour changed recently with the updated dashboard URI inputs?
  • Is wildcard subdomain + fixed path still officially supported for Allowed Callback URLs?
  • If not, why do these callback URLs continue to work correctly at runtime?
  • Is this a known regression or validation/UI issue?
  • What is the recommended approach now for multi-tenant or preview-environment deployments using dynamic subdomains?

Thanks.

3

Hi @andy.pattenden

Welcome to the Auth0 Community!

Thank you for reporting this behaviour to us. Allow me to share some details to help overcome the issue:

  • if you are a multi-tenant approach, it is recommended to use {organization_name} instead of wildcards ( * ), as this ensures that only subdomains associated with the organizations in your tenant will be allowed;

  • for preview-environment deployments, if you need to continue using wildcards ( * ), it could be more reliable to use the Management API to call the /api/v2/clients/{id} endpoint, as the API typically bypasses the same front-end validation checks and will allow you to save valid wildcard URLs;

  • a great alternative for the time being would be to use, as much as possible, centralized/static callback URL ( example: https://auth.example.com/callback ) and handle the internal routing to specific subdomains/paths via the state parameter.

It is possible that any recent change to the UI can contain unknown bugs that our teams will be working on fixing in a timely manner. You report does help us and it will be further directed.

Please let us know if the behaviour that you are seeing changes in any way and if the above steps helped overcome the issue.

Best regards,
Gerald