Gotchya! Thanks for sharing that!
Hi Konrad,
We are facing the same issue. Do you have an update on this?
BR, Markus
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.
1 Like
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.
3 Likes
That makes sense. Thanks for your response!
2 Likes
Hi @konrad.sopala ,
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.
Thank you
3 Likes
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?
3 Likes
@perfectpattern You may find this useful: Support/Replace Organization prompt screen with "choose organization" during login - #17 by adam.housman
1 Like
@aaron.hardy : I understand the user story behind the feature you posted. Very nice, BUT:
There are people who implement their own “organization choosing” dialog/mechanism and you could help them with a simple parameter. Instead you implement a whole dialog …?!?
Of course there is another option:
Allow that users can set the organization id at organization creation.
I understand that the organization name might be something “not-technical” for you, so maybe you do not like that we put OUR technical tenant id in you human readable organization name. If the technical organization id could be defined by us, we could build the mapping in there.
Just a thought…
I still think it is very uncomfortable, that you generate IDs by yourself and then expect every other system to know it and do their own mapping. This mapping should happen in auth0 and I should be able to call you with my tenant-ID (regardless of whether it is stored in organization id or name at auth0).
2 Likes
Is there any update on whether organization_name will be supported as a query parameter?
On a related topic, am I correct that universal login identity first feature with the enterprise Home Realm Discovery only works once in context of an organization? Seems to be the case from my experimenting, if I try to authorize without any organizationId parameter and identity first enabled then receive an error that there’s no organization parameter.
We would find the usage of the organization_name parameter extremely useful as well in our use case. Any update with regards to whether this is an Auth0 roadmap item along with its progress and potential release date would be much appreciated.
I am struggling with the same problem. Terribly annoying that Auth0 does not allow quick and easy use of org_id during Authorization Code Flow.
Is such functionality planned at all and when?
1 Like
Hi all, we’ll be shipping support for Organization names in login flows next month. Thanks for the feedback and stay tuned for the update.
2 Likes
Thanks for the update Adam!
Thank you a lot, Team!
1 Like
Hi all, I’m happy to announce that we shipped support for organization names today!
You can read about it on the Changelog. Auth0 Changelog
Thanks for your feedback and keep it coming 
1 Like
I started using it a few days ago, I thought it was already released 
Made for a far simpler solution, so much appreciated. However I have seen one issue. When handling an organisation invitation the authorize endpoint then seems to only accept org_id, if org name used for an invitation login then get error “invalid invitation ticket (organization mismatch)”. I have managed to workaround this since the invite login includes org name and org id as parameters but seems rather inconsistent.
1 Like