How come "Allowed Web Origins" does not allow wildcards?

We too are a multi-tenancy app with a subdomain per tenant. The list of Allowed Callbacks, Allowed Web Origins and Allowed Logout Urls is getting REEEEeeeeaalll Long. I’m expecting to hit a limit of some kind any day now. We either need to look at programatically creating an app client per domain or migrate away from Auth0. Wildcards for all of these would solve everything.

An update but not really. More like a BUMP :wink:
I’m able to get wildcard subdomains working for Callbacks and Logout urls, but naturally not for Allowed Origins.
So handling my product’s own subdomains created per each of our customers eg, mystuff.website.com or hello.website.com requires an Auth0 Management API call to add each new subdomain to its Allowed Origins.
And for fully external customer domains mapping to our product a Management API call to add their domain to our Callbacks, Logout and Origins fields.

As i mentioned, this list of domains grows all the time. Starting to rethink Auth0 for multi-tenant but too in <3 with its features.

Unfortunately no update on this front.

Thanks again for following up.

1 Like

No worries, we’re here for you!

I know i’m simultaneously asking these questions here and Allowed Callback URLs field limitations? - #11 by steve1 however just looking to solve this so i’ll do my best to find solutions.

So, in the scenario of a single Auth0 tenant tied to a single web app. I map various subdomains and instruct to configure DNS for external domains for my customers to point to our single platform CNAME. eg, mycommunity,app,com or somethingelse,aaa,com or community,customer1,com (which points to alias,aaa,com).

Hurdles and options that seem worth considering so far:

  • Allowed Callbacks
  • Allowed Web Origins
  • Allowed Logout Urls

When a new customer is created on my multi-tenant platform, using the Management API i could either:

  1. Use a single Auth0 Application (Client) and add the new domain using Auth0 Management API v2 to update callbacks, web_origins and allowed_logout_urls
  2. Use multiple Auth0 Application (Client), one for EVERY customer domain using Auth0 Management API v2 and then adding the relevant connections (eg, ‘facebook’) using Auth0 Management API v2 enabled_clients

My issue with 1. is the 100 domain limit on callback urls. Eventually you’ll hit it.
And my issue with 2. is similar, is there a limit on the amount of Auth0 Applications (Clients) we can create, not to mention how unwieldily that will get. Plus i can’t easily bundle the Auth0 ClientId with the app, will have to query it per tenant based on hostname.

I’m leaning towards 2. even though i have been using 1. for some time, just feeling like i’m on borrowed time and eventually the limit will be hit.

edit However after some thought … can you do Single Sign On (SSO) between Auth0 Applications (Clients)?? perhaps not.

Anyone else have a suggestion? Perhaps an insecure universal callback url? :sweat_smile:

Would like to throw my vote in the ring. We’d really like to use wildcard origins for our staging environment. I think for now I’ll manually (w/ script) generate as many review app URLs as the input box will accept. But clearly this is not ideal.

One solution if you’re really sticking to the OAuth 2 recommendations would be to release a tool that makes the client app spin up/teardown stuff @nicolas_sabena mentioned easy. Integrate with Heroku/Netlify if you can

Thanks for adding to this one @bogdan! Just relayed this feedback to appropriate team!

1 Like

Right @bogdan as @nicolas_sabena said earlier up top:

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.

I’m currently using the management API to append urls but the list is long. Will look into using the management api to create a new Auth0 client per domain (eeeep, this list of clients will be long). Unsure if this will mess with SSO between domains but hey, only one way to find out.

Presuming i’ll need to:

1 Like

Update: now have wired up api calls to new create new clients for each subdomain. Annoying but functional.

2 Likes

Thank you a lot @steve1 for sharing it with the rest of community!

I’m doing my best to advocate for that but as you guys know everything is in product managers’ hands.

At the least, the UI needs to warn you that wildcards are invalid in the “origin” field. Thank you!

Thank you for providing your opinion on that @jbailey! I just passed it to our product team.

Apologies in advance in case my exact use case is already on your radar, I want to give you the opportunity to add my data point.

As mentioned by others, we’re using Netlify deploy previews that generate a subdomain that looks like this: https://deploy-preview-102--<netlify-account>.netlify.com/callback
where <netlify-account> is a placeholder for a unique identifier that’s only tied to our Netlify account and 102 is the identifier of the PR on github.

I would like to add the following wildcard, which should cover all future deploy previews:
https://*<netlify-account>.netlify.com

As far as I understand, this wouldn’t pose a security risk, assuming Netlify makes sure that no other Netlify customers will get a subdomain with our <netlify-account> suffix, which I think is a reasonable assumption to make. I understand that https://*.netlify.com would be a bad idea, perhaps this is a restriction you can build in, or a trigger for a warning or something.

Thanks!

1 Like

Thanks for providing that context! I will pass it through to our product team!

I would also like to vote for this feature for the same reasons as other people (feature/testing/demo branches)

I have use cases of creating demo branches to demo the tools to different stakeholders.

I do wonder how long/what it takes for the development team to get to a feature since this issue was opened in 2018.

Thanks for advocating for this feature @smblee!

I would try to discuss it once again with the engineering and product team what are the roadblocks here and see if there is some public guidance I can reveal.

Yes, our team needs this as well

Hey there @fh-jashmore!

Can you provide us with your usecase so we can have some justification for our product managers? I believe that going to them and saying them that we have another user who request that feature without any usecase won’t make the whole thing better. Thank you!

1 Like

We do face the exact same use case as @edor with Netlify and as the rest of the community are not able to follow your product teams reasoning. Hope to see the issue get fixed soon. It is always sad to see product managers following their own agenda, ignoring their clients needs. I would really like to see PM joining the discussion and not hiding out.

1 Like