We are building a multitenant system, where authentication is based on Auth0 and every tenant is an Auth0 organization. The frontend is implemented in React and is using auth0-react for authentication needs. Our Auth0 client/application is configured to display organization prompt by default. During the login flow our end users have to provide their tenant name (that is, type it in the organization prompt).
We want to improve login experience for customers that connect 3rd party IDPs (for example, their own Okta) to our Auth0 by providing them a bookmark URL that can be used in their Okta SSO portal. Ideally, this URL should sign-in authenticated end users in our app without additional prompts.
This looks feasible. However, at this moment there is no way to send organization name in Auth0Provider properties - primarily because this is not supported by Auth0 server in authorization code flow (as stated by React SDK devs in this GitHub issue).
Proposed Solution
Ideally, we would like to see Auth0 server being enhanced to accept organization_name attribute, which will allow us to skip organization prompt in a way similar to what organization attribute does today.
Available Alternatives
There are a couple of alternatives that we thought about.
Option 1
We can send organization ID to make the flow work. This means that we will have to expose internal ID of the Auth0 organization, which corresponds to the customer tenant. This solution is prone to the future internal changes, system migrations etc, and will force us to maintain those IDs pretty much forever.
Option 2
We can expose an unauthenticated API that will provide name-to-ID mapping and will be used on the SPA side to convert tenant/org name to organization ID. This API will have to utilize Auth0 management API internally - which in turn is subject to Auth0 rate limits. This means that we will have to implement own rate limiting, DoS protection etc.
Both alternatives introduce unnecessary complications to our systems. This feature would make our life much easier!
This is a POC to replace the existing Org picker page with something more dynamic. I havn’t found a way to pass any url context through tho, since you just see that state parameter.
Hi, we’re also building a multitenant SaaS and we would like to streamline the way our client’s users use Auth0 for logging in. We would also very much like first-party support for a organization_name attribute in the Auth0 server. Is there any update on this issue?
+1 for this feature, we’re currently using a lambda to exchange the name of the id using the management api, but would prefer to use the name directly
To further expand on our use case, we also want to allow bookmarking of organization names via URLs that we can give to customers, and bypass the Organization login page where you have to type your organization name.
So what we’re doing is giving customers something like
https://{organization-name}.myapp.mycompany.com
and then calling a custom lambda we’ve written from JavaScript to exchange this organization-name-as-subdomain concept for an organizationId that can then be used with the Auth0 JS client library
would be much better for us if we could just use the Auth0 JS client library with the organization-name directly…
We’re running into this as well. This gap in functionality definitely makes the login flow cumbersome. @khitrenovich, I’m curious to know which of your two options you went with in the meantime.
@aaron.hardy -
We decided that option 2 is either too complicated to implement or too risky, so we went with option 1. We’ve added “copy link” buttons to various places in the app, and those links have org ID embedded. We intercept those links in the app and redirect user to (re-)authentication with the proper organization.
Thanks for the reply! I’m actually surprised you went with option 1. I’m thinking about going with option 2. Just to make sure I’m not stepping into a security trap, why do you feel option 2 would be risky (I assume you mean risky from a security standpoint?).
@aaron.hardy -
Option 2 involves building a component that will effectively translate unauthenticated calls (from browser to our endpoint) to authenticated and rate-limited calls (from our system to Auth0). So either we will implement our own rate-limiting system (which will be complicated, given the pre-authentication stage of the flow) or we won’t, leaving this system vulnerable to DoS attacks - malicious excessive calls will eventually lead to throttling/blocking us from calling Auth0 (this is where the “risky” part comes into play). Being a small start-up, we decided against spending precious resources on the system that is not our core competency and went with option 1, but I totally understand why in a bigger place option 2 with proper protection might be preferable.
Like the others in this thread, this has come up for my team, and to really take advantage of the organizations feature, being able to send the organization_name in the provider properties makes a lot of sense. Is there any news on timelines of when this feature could be available? Because like mentioned by others, I would prefer to not open up an unauthenticated endpoint to just swap the organization_name with the id.
We have the same problem.
Be honest: Who wants to interact with auth0 via the ID that chooses auth0.
Please simply add another parameter “organization_name” and everything is fine.
Is there already an ETA?