I’ve created a successful Auth0 web app client using a wildcard subdomain in the callback url. Works like a charm. Now for my mobile app, I have a custom protocol in the callback url: com.xtinguishers.tech:// This is so my app can open up when the callback arrives. So my redirectUri looks like:
But when trying to authenticate Auth0 tells me that the redirectUrl is not approved. Is this a bug, or is there a security reason why wildcards cannot be allowed in combination with a custom protocol (should be common use case for hybrid apps using Auth0).
The analysis is spot on and I totally agree. Let me back up on my question one step. My situation is your last one: a single, mobile app. I do indeed ask the user for the tenant’s “domain” the first time they open the app.
My original question should have been, how to pass a parameter to the authorize endpoint that I can access from a Rule?
I was basically shoving this “tenant” parameter in the RedirectUri so that way in the Rule I could parse it out and use it in the rule. The RedirectUri was the only was I could see of passing a param from my application to Auth0 rules.
The reason I need the tenant “domain” in my rules is 2 reasons:
Primarily, in the rule, I call my API method “GetValidUsers” that returns from my backend a list of all email addresses that are allowed to be used for login for this tenant. The tenant “domain” is required for this.
I like to embed the tenant domain into the token, for a secure and consistent way that my app and api can know what tenant to deal with.
So…what’s the best way to pass this tenant parameter to Auth0 rule?
I might be missing something, but in general, sub-domains are used in multi-tenant SaaS web solutions as a good way to provide a customer specific and direct entry point into the application.
A single domain could be used and the customer would just input/choose something that would identify the customer/organization and the application would then update/adapt itself accordingly. However, having the sub-domain means the adapted/customized experience can be provided from the start. This is useful because in web applications end-users need to tell the browser where to go, so they might as well use an URL that is strictly associated to their organization.
For mobile apps I see this a bit differently; the user has to install the app. In a multi-tenant world you would either have different apps for each tenant or a single app. If you have different apps and as such they can be installed at the same time, they should be using completely different configurations and URI schemes so the above issue would not apply.
If it’s a single app I also don’t see how the sub-domains would help. In a web app the sub-domain would be in use even before the user authenticates so you would know the tenant from the URL itself. However, in a mobile application the redirect URI is called when the user is already interacting with the app and is mostly already authenticated so if you already have user information you can get the tenant from there instead.
In conclusion, what you mention is not supported as the redirect URI in Cordova (assuming use of auth0-cordova) is auto-generated and the host part is your Auth0 account. However, this does not seem to cause an issue because if you only have one application for different tenants you can only provide customized experience after the user provides some input and if you have multiple mobile applications then they should use different configurations.
Update
Additional parameters sent to the authorization endpoint are surfaced in rules through context.request.query and additional parameters sent to the token endpoint are surfaced in context.request.body. This would allow you to send an extra parameter like x_tenant.
However, not all libraries will allow you to send additional custom parameters so for your use case you could also consider sending the information as part of the scope parameter as you’re performing authentication with the objective to gain access to a certain scope/tenant; for example one of your scopes could be tenant:[tenant_id_here]. Your rule would parse and process this specific scope.
The important part is that with both methods of passing this information the information itself can be controlled by the end-user so you would need to validate it. You already seem to be using by calling GetValidUsers but I wanted to mention this in case someone else follows a similar approach.
The namespace requirement if for custom claims included in JWT tokens so from the perspective of sending the custom scope it would not be required and at most you should only ensure that the custom scope would not clash with any other OIDC scope or your own API scopes if applicable. If you then include the the tenant value as claim inside an issued token then at that point it would indeed need to use a namespace.