Subdomain authentication flow

Our app hosts customer domains at {org_name}.myapp.com. We want to redirect users to their subdomain after login, but we don’t want to require users to type in/remember their organization before initiating the login flow (which is required to use Organization URL parameters - see docs).

The approach I’m taking (inspired by this post) is to have an auth.myapp.com domain that redirects users to Auth0, and is also the callback URL. After login is completed, auth.myapp.com will manually redirect users to their subdomain. Note that I am setting the cookieDomain=.myapp.com to allow the subdomains to access the requisite cookies.

This is nearly working, however, when I redirect to {org_name}.myapp.com, because the callback URL is set to auth.myapp.com/callback, the getTokenSilently API uses the callback URL origin of auth.myapp.com, which doesn’t match the user’s actual origin {org_name}.myapp.com. This prevents the token flow from succeeding (the /authorize?prompt=none request succeeds but has the wrong targetOrigin, so the /token request never follows)

I could fix this by adding *.myapp.com to the allowed callback URLs and then using {org_name}.myapp.com as the callback URL, but from what I understand wildcard callback URLs are discouraged for security reasons.

Feels like this should be more straightforward and maybe I’m taking the wrong approach. Is there another way to do this? I suppose the “other way” is to use {organization_name} in the callback URL but I would rather not force my users to type in their organization before logging in.

Managed to get one step closer: I can dynamically set the redirect_uri to the current origin (either auth.myapp.com/callback or {organization_name}.myapp.com), and when on an organization’s subdomain, pass the organization as an authorizationParam. This allows me to set my Allowed callback URLs to be auth.myapp.com/callback,{organization_name}.myapp.com/callback and not use a wildcard for the callback URL.

However I still need to use a wildcard in the Allowed Web Origins list…which seems like a lower risk than the Allowed Callback URLs but is still not ideal

Actually, reading the application settings docs more carefully:

Do not use wildcard placeholders or localhost URLs in your application callbacks or allowed origins fields

This reads to me like it’s referring to “Allowed Origins (CORS)” and that a wildcard might be okay in the “Allowed Web Origins” field. Would appreciate if I can get confirmation on this from someone at Auth0
EDIT: Nvm, looks like this is explicitly discouraged still How come "Allowed Web Origins" does not allow wildcards? - #125 by randynasson

Seems like Auth0 is 90% of the way there towards enabling this multitenant subdomain approach…in the short term looks like my best bet is updating the Allowed Web Origins field explicitly for each tenant :frowning: