I have a a multi tenant application that allows each client to either use their own custom domain, or a subdomain of ours. While small, we are able to setup each client as their own Auth0 application, but entity limits of 100 will at some point make make that infeasible. I suppose we could also store long lists of allowed URIs under single applications, but that also gets really cumbersome to manage at some point. I’m just curious about what the best general practice is in a case like this.
Also, does the auth0 API facilitate this kind of management to where I can automate the auth0 configuration of new clients as they are onboarded?
For the last part you can use the Auth0 Management API (Auth0 Management API v2) to automate the creation and management of client applications. There’s reference information on how to call the Management API from your backend at (Get Management API Access Tokens for Production).
In relation to the scenario itself for the ones that use a subdomain of one of your domains you could consider using wildcards (https://auth0.com/docs/applications/wildcards-for-subdomains) to simplify that process. However, for the ones with their own custom domains this could be more involved and I don’t recall going through this exact use case before; I’ll try to do some search on this to see if I can come up with possible suggestions.
Thanks for looking into it! I do have an app setup with wildcards for the product domain and that has worked well. We are seeing that it will be a common request to use custom domains though so trying to get a plan in place early.
I haven’t yet got to a conclusion on this, but can you expand on how the custom domains approach you use work? As in, you initially mentioned that it is a multi-tenant application so I’m assuming the custom domains will be a CNAME or some sort of verifiable reverse proxy. In other words the customer won’t get a dedicated environment, just another means to get to the multi-tenant one is that it?
That is correct, the client creates a CNAME reference in their DNS management as an alias to our domain. We then map that configured domain to a client session, all in the context of a multi tenant shared environment. Each client can have their own own auth0 application client id.
Thanks for clarifying; I confess I haven’t really confirmed this, but I think by allowing a custom domain scenario like that one due to non-functional requirements like security it’s likely you’ll either be forced to have one client application per custom domain (as well as dedicated connections just for that customer) or have other means to ensure that a potentially mischievous custom domain customer can’t use the custom domain as means to try to get their hands on some tokens associated with users of your other customers.
In other words, if you use a single application and allow flows where token are delivered or flow through the user-agent that custom domain could be used to possibly trick people from other customers to login into your service while their tokens would be delivered through the malicious custom domain that could temporarily cease to be a CNAME.
With the above in mind the issue of how to manage redirect URI’s may be more about security than ease of configuration and to be honest I think having a custom domain on it’s own client application could be beneficial from the security perspective although there’s the issue of entity limits in self-service subscriptions.
I do appreciate your continued follow up on this, and that does make sense on the need for an application per client to lock down security and prevent sneaky abuse. I’m hung up on entity limits though, and surprised that this scenario hasn’t been encountered anywhere else. If when the application reaches 100 custom domain clients (under the current limits) I’ll be in trouble. Do you know if there are any considerations for more flexible limits?
So…informally I have seen it mentioned that we would possibly consider to have some additional flexibility in terms of entity limits in order to better tackle scenarios that may need a significant number of entities without technically being dependent of features that would imply an enterprise subscription. However, this was informal conversations so can’t confirm if anything would happen.
I would strongly suggest that anyone with use cases that may be constrained by entity limits to share them through Auth0: Secure access for everyone. But not just anyone. so that our product team can be better informed on how the limits are impacting certain scenarios.