I work on a multi-tenant service that allows users to be members of multiple organizations. External users are typically only members of a small number of organizations, so the current Organization Picker works great for them – either they bypass the picker to log in to their single organization, or they select from a short list.
Internal users, on the other hand, often have access to well over 100 organizations. For example, our support staff needs to log in to organizations to understand problems reported by the external users. For them the current Organization Picker is inadequate, since it is only capable of displaying 20 organizations.
My suggestion is that the Organization Picker become a searchable drop-down list once the number of organizations exceeds 20, and include all of a user’s organizations. Typing a small part of the organization name to filter the list would allow them to easily select the organization they want and the drop-down control would occupy far less real estate on the form than 100+ individual buttons.
Ditto, the dashboard my team has built and supports needs support for more than 20 orgs in the picker. It should be rather easy to impl. and I’m not quite sure how this was released without pagination-like support.
Hi all, until such a time as support for more than 20 orgs is added to the organization picker, please consider using the MGMT API to fetch organizations from within your application. You can fetch 50 orgs per page so pagination will be necessary. You may also consider using an Organization Switcher in your internal app similar to what is demonstrated in the UI Components: Auth0 Lab - UI Components
Agreed here. WE have implemented a TEA tool that helps keep the total amount at any given time in check (we have many thousands of tenants/clients) while also being a good security practice. However, even with aggressive expiry periods, 20 is limiting for team roles such as a support agent.
Some sort of filter/search would be greatly simplifying.
If you support many applications through your tenant (and esp if you support third-party applications), then implementing an org picker in each one is probably a non-starter. Doing it in the auth flow is the only desired outcome.
One (the only?) option for this is to create your own org chooser with a redirect action for when the auth flow does not contain an organization. Once you have their org choice, you can redirect the user a second time to start a new /authorize?... flow using the same parameters from the first flow (event.request.query), and adding the organization=<auth0_org_id> query param with the auth0 organization ID they picked as the value. (Note: you’ll need a way to persist these params across the redirect. user metadata or user appmetadata can work). Preserving the original authorize flow parameters is important so that the new flow finishes at the same callback_uri and arrives with the state param the flow was initiated with. Auth0 SDKs/libraries will verify that the same state param is returned on the callback to your app. If they don’t match, you’ll get an error about a state mismatch.
Unfortunately, you cannot simply redirect to the new /authorize?... call with api.redirect.sendUserTo(...) because Auth0 adds/overwrites the state param on every redirect URL. Normally you’d use this state param to trigger the /continue call to finish the redirect and resume the action execution, but we don’t want that here because we don’t intend to complete this redirect; We’re starting a new flow that should end at the callback the first flow should have. So the problem is that when we construct a new authorize URL containing the original state (and the added organization param) and pass that to sendUserTo, auth0 overwrites/corrupts the state param and your app will not accept the callback because of a state mismatch.
What you need to do instead is use api.redirect.sendUserTo(...) to redirect the user to some simple page or endpoint that you control and include the new /authorize?... URL as a urlencoded query parameter. Make that page or endpoint simply redirect the browser to the URL in the parameter. That will start a new auth flow with the organization the user chose from your custom org picker, and it will end at the callback from the original auth flow with the state from the original flow.
Assuming you have auth0 sessions turned on, this new flow shouldn’t require any more user interaction (like another login). The might just notice the couple of extra redirects.
@adam.housman are we reinventing the wheel to rebuild an org picker ourselves with the MGMT API?
how long do you think it would take 1 auth0 engineer to add pagination to the organization picker you all supply? This has been a massive limitation for us