I really hope they listen on this one! we’re considering rolling out our own auth because of this.
it seems crazy that Auth0 does not help in this discussion? I will try to get their attention on Twitter, maybe that will help.
Everytime someone posts a PR to our SPA, we generate a build and deploy it to a server which has a custom NGINX config. This allows us to have a pr-commit-sha.builds.io url. Without the ability to have a wildcard “Allowed Web Origins” we will have to manually add each PR build url to this section of our Auth0 Client.
I just wanted to clarify the reasoning behind the decision of not supporting wildcards: as Matias says we are following recommendations on IETF’s OAuth 2.0 Threat Model and Security Considerations. There are many examples of security exploits that took advantage of wildcards usage in domain listing. We understand the added friction that this causes but decided to opt for the more secure option of being explicit on the domains allowed.
As some pointed out, older fields still support wildcards. The main reason these still works is backward compatibility, but this is likely to be addressed at some point as well.
For the types of automatic deployments that you are describing, I would suggest using our management API to automate the provision of a new client when deploying to a new domain and the deletion of that client when tearing down the deployment. This will keeps things tidy (avoiding one client with a long list of whitelisted URLs) and will help to a stronger deployment procedure (because you’ll have a fresh and reproducible Auth0 client in each deploy).
You can also use the management API to patch an existing client and add the new domain to the list, but if you chose this option I would at least leave the production client separate.
I understand this is not the answer you were looking for, but at least I hope it helps to understand the motivation.
Heroku review apps and Netlify deploy previews are becoming a very popular and powerful workflow, especially I imagine amongst Auth0 target user base.
For such disposable review apps, that contain dummy data, and are running on development Auth0 tenants, there is no threat whatever the IETF considerations around wildcard subdomain exploits since there’s nothing to exploit - just an empty app on a temporary and disposable sub domain.
Heroku review apps and Netlify deploy previews can be setup in minutes, just by adding an integration to a GitHub repo, I don’t think trying to manually bolt on calls to the management API is a reasonable suggestion in this case. Unless you’re considering an Auth0 GitHub integration that could automate this?
Anyway, I’d urge you to reconsider this decision and empower developers to judiciously enable this option in scenarios where there is obviously no threat. Can’t this be solved with some UI messaging, i.e. put the wildcard options behind a DANGER area in the settings UI, with clear messaging?
We appreciate your suggestion and sharing the use case. It would be great if you could share with our Product Feedback form at https://auth0.com/feedback so that the team can consider and reach out to you if needed.
Thanks for sharing your feedback. Thanks also to everyone else who’s contributed all the way back up to Andy who started this thread! It’s a great discussion, and the Auth0 product team values your opinions and ideas.
I realize that the lack of wildcard support for Web Origins is frustrating from a development and testing perspective, and we recognize that it’s something we’d like to make better. Although I cannot commit to a specific date or outcome, I did want you to know that we’re looking at this and it will be considered in our ongoing prioritization process.