I really hope they listen on this one! we’re considering rolling out our own auth because of this.
2 Likes
it seems crazy that Auth0 does not help in this discussion? I will try to get their attention on Twitter, maybe that will help.
4 Likes
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.
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.
4 Likes
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?
8 Likes
We appreciate your suggestion and sharing the use case. It would be great if you could share with our Product Feedback form at Auth0: Secure access for everyone. But not just anyone. so that the team can consider and reach out to you if needed.
Hi Jed!
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.
5 Likes
Is there a way for silent authentication if i’m using subdomains and dont want to put all subdomains into my "Allowed Web Origins " settings?
using renewAuth instead is causing me circular reloading of the page…
Bump.
I’d also encourage Auth0 to implement wildcard CORS. Auth0’s whole reason for existence is that devs can implement auth faster than rolling their own. People who need/want tight security are likely rolling their own, with time/money allowed for it if it’s important enough for them. If Auth0 wants to implement super tight security at the cost of developer convenience, who exactly are you selling your services to? I don’t mean to be too critical, but it feels weird to me. It’s like hopping into fast food, and there’s a chef telling me to wait two hours for the perfect steak. No. I stopped by this establishment for quick service, which is not a ding against you per se. I thought that was what you were advertising.
sincerely,
Jun
2 Likes
Hey @jun!
As @randynasson said, we are really aware of the struggles you face in this matter and we do take this constructive feedback very seriously. What I can do at the moment is to apologise you for any inconvenience. Our product team already received that feedback and as any feedback from any of our community developers this feedback is evaluated and will be communicated or worked on appropriately.
Let us know if we can do anything else for you!
Once more we’re terribly sorry for inconvenience and thank you for patience!
+1 for this feature request.
It’s not just a problem for us during development & testing. We have a multi-tenancy app with a subdomain per tenant. We’re going to push forward using the management API to patch Allowed Web Origins for each new tenant but without wildcard support we may have to move away from Auth0 in the future.
Are there any limits on the size of Allowed Web Origins field?
It’s not friction – it removes one of two use cases for auth0.
As for security concerns… isn’t that why we all signed up with auth0 in the first place? So we can rest easy knowing you figured it all out?
Since I first signed up, more and more layers have been peeled away from auth0 because they turned out to be insecure. Instead of solving the underlying issues… more times than not, the decision has been: punt to users.
I’m feeling very much like I was promised a zebra and it turned out to be a painted donkey. And now I need to worry about cleaning off the stripes.
2 Likes
Hey Cory!
I totally understand the reasoning you provided and we are super sorry for that! Along with Nico we would really love to help you with any issues / roadblocks you face. I know that we’ve asked it multiple times but would really really appreciate if you can share with me over DM or here wherever you prefer a concise and constructive description of roadblocks / issues / errors / you face so I can provide it in the best form to our product team.
Thank you a lot for understanding and once more terribly sorry for any inconvenience!
+1 for this question. Has a solution been made available?
We are also building a multi tenant solution with one subdomain for each customer. It is unfortunate that we have to introduce a dependency to the Auth0 Management API, where we before could manage our subdomains through pure SQL.
1 Like
Hey Everyone!
As I stated it in another thread. The only thing we can do for now as a developer community team is to advocate for your needs and make sure we are able to effectively relay it to appropriate product and engineering teams. As any other software product company in the world we have issues and errors reported by our clients and developers that need to be prioritized based on the severity and number of people reporting them and then fixed.
Thank you a lot for providing us with more reasons and issue descriptions. We constantly do advocate for them and will let you know once we have any updates to share.
1 Like
+1 We have deployable feature branches with dynamic URLs. Not having a wildcard option is causing problems
@konrad.sopala - My team and I are in the same boat as @karlis.filipsons - we are using dynamic URLs in our branch deployments and the inability to use wildcards for subdomains is very problematic.
1 Like
Thank you a lot @longjaso for providing that context. I’m regurarly making sure to advocate for your needs!