Ability to provide organization name during Authorization Code Flow

khitrenovich · November 5, 2021, 2:12pm

Problem Statement

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!

konrad.sopala · November 5, 2021, 2:36pm

Woow! Thank you for providing such extensive context. I’m gonna relay that to our product teams!

Thom3189 · December 16, 2021, 8:32am

We are also running in to the same issue. Hope to see this implemented soon!

konrad.sopala · December 16, 2021, 12:03pm

Thanks for adding your +1!

KSchmi · January 13, 2022, 2:18am

Another solution to improve the Org picking experience for your users is that you could inject javascript on the org picker page by customizing the universal login page template, Customize New Universal Login Pages.

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.

<!DOCTYPE html><html>
  <head>
    {%- auth0:head -%}
    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.1.1/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-F3w7mX95PdgyTmZZMECAngseQB83DfGTowi0iMjiWaeVhAn4FJkqJByhZMI3AhiU" crossorigin="anonymous">
 
  <style>
    .orgWidgetVisible{
      display: flex;align-items: center;justify-content: center;
    }
    .orgWidgetHidden{
      display:none
    }
  </style>

  </head>
  <body  >
    <div id = "auth0Widget" class="orgWidgetVisible">
    {%- auth0:widget -%}
  </div>

    {% if prompt.name == "organizations" or prompt.screen.name == "organization-selection" %} 

    <script>

      function showOrgPicker(){
      
        let widget = document.getElementById("auth0Widget");
        widget.classList.toggle("orgWidgetHidden");

        let orgPicker = document.getElementsByName("orgPicker")[0];
        orgPicker.style.display = "block";

        let orgButton = document.getElementById("btnShowOrgPicker");
        orgButton.style.display = "none";

      }

      function orgSelected(org){
        
        let widget = document.getElementById("auth0Widget");
        widget.classList.toggle("orgWidgetHidden");

        let orgPicker = document.getElementsByName("orgPicker")[0];
        orgPicker.style.display = "none";

        let txtOrgName = document.getElementsByName("organizationName")[0];
        txtOrgName.value = org;
        txtOrgName.focus();

        let orgButton = document.getElementById("btnShowOrgPicker");
        orgButton.style.display = "block";
      }
  </script>
   <div style="display:flex;justify-content:center;align-items:center; margin-top: 20px;">
        <div>   <button class="btn btn-secondary" id="btnShowOrgPicker" onclick="showOrgPicker()" >I don't know my organization Name</button></div>
      </div>
 
        <div name="orgPicker" style="display:none;color:white" >
            <table class="table">
              <thead>
                <th>
                  Organization Name
                </th>
                <th>
                  Organization
                </th>
              </thead>
              <tr>
                <td><button class="btn btn-secondary" onclick="orgSelected('appleconn')" >appleconn</button></td>
                <td>Apple</td>
              </tr>
              <tr>
                <td><button class="btn btn-secondary" onclick="orgSelected('testorg')" >testorg</button></td>
                <td>The other org</td>
              </tr>
        </div>

 
    {% endif %}

  </body></html>

tgirard · March 4, 2022, 4:06pm

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?

konrad.sopala · March 7, 2022, 8:25am

Unfortunately not yet. Sorry for the inconvenience and thanks for advocating for that! I will let you know as soon as we know something!

thomas.liversidge · April 6, 2022, 10:10am

+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

konrad.sopala · April 6, 2022, 12:28pm

Thanks for providing that context @thomas.liversidge !

thomas.liversidge · April 6, 2022, 12:41pm

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…

konrad.sopala · April 6, 2022, 12:44pm

Gotchya! Thanks for sharing that!

markus.baumgartner · July 13, 2022, 10:38am

Hi Konrad,

We are facing the same issue. Do you have an update on this?

BR, Markus

aaron.hardy · August 10, 2022, 8:10pm

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.

khitrenovich · August 10, 2022, 8:36pm

@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.

aaron.hardy · August 13, 2022, 12:07am

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?).

khitrenovich · August 15, 2022, 2:15pm

@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.

aaron.hardy · August 18, 2022, 8:58pm

That makes sense. Thanks for your response!

nathan.dilucca · September 1, 2022, 4:58pm

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