Hi folks - i’m another one in a situation where I have a multitenant application where each customer gets their own URL. Each tenant needs their own subdomain because of how the app is architected internally, and mirroring our tenant list in the Auth0 configuration via the API just isn’t feasible or maintainable (especially since it doesn’t seem the limits of that field are documented anywhere).
To help your product managers understand the design here, each tenant in our system receives their own server container with an entirely separate instance of the product. We don’t want to centralize auth at one URL because each tenant has the flexibility to run different versions of the application, and the authentication logic should be updated along with the rest of the app to avoid breaking changes impacting tenants in an unpredictable way.
I’d like to understand nicolas_sabena’s post more in depth about what the risks are that Auth0 is trying to mitigate by disallowing wildcards in this scenario. We completely control our domain, so anyone who can redirect one of our subdomains can just as easily redirect our root domain. I can easily understand the risks for someone blanket authorizing an entire cloud provider domain they don’t control, like *.azurewebapps.net, but for us, the subdomains and root domains are exactly equivalent in control and authoritativeness. And skimming that RFC, I don’t see anything specifically mentioning wildcards - lots of discussion about validating the original URL is intended, but nothing that says that securely defining a range of acceptable URLs to be validated against is a risk at first glance.
Could there perhaps be a compromise that allows Auth0 to verify a TXT record in a domain to prove control before allowing it to be whitelisted?
I’ve gotten 95% of the way to launch because wildcards work fine in the other fields, and it’s only now that we’ve been doing more significant testing in prod with multiple tenants that requires refreshing that we’re realizing this limitation exists. We’re pretty much screwed and are trying to figure out whether we have to rip out Auth0 entirely at the last minute and replace with a different auth solution at this point.
Any mitigations or advice you can offer would be greatly appreciated.