Hi everyone.
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.