Make authorize URL configurable

[arjenvanderende]

Checklist

• [X] I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• [X] I have looked into the documentation and API documentation, and have not found a suitable solution or answer.
• [X] I have searched the issues and have not found a suitable solution or answer.
• [X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• [X] I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

We use Auth0 as identity provider for our globally available platform. Because of regulations for some of our users we are required to store their data in the country they are located in. We use separate database connections for some countries. We have a custom country picker page that forwards users to the Auth0 universal login page with the correct connection for the country they have picked. To make sure that users can log on via web and mobile applications, all logins must go via the custom country picker page. The country picker page is hosted on a separate domain and is OIDC compliant.

For our web application we use auth0-react to handle authentication which works nicely. We're trying to integrate the custom country picker page. Because it's hosted on a separate domain, we need to override the authorizationUrl. Because this is hard-coded we're unable to do so.

Describe the ideal solution

Have an option to override the authorizationUrl.

Suggestions for alternative solutions are welcome.

Alternatives and current workarounds

For the short term we're considering forking the auth0/auth0-spa-js and auth0/auth0-react libraries to make our use case work. This is not ideal, because we like to stay up-to-date with the updates of your libraries. After forking each release creates additional work/maintenance for us to stay up-to-date.

Additional context

I see that there have been similar request in the past, like https://github.com/auth0/auth0-spa-js/issues/890 and https://github.com/auth0/auth0-spa-js/issues/904. Those requests were rejected because the issuers tried to use the Auth0 library with non-supported identity providers. We're using Auth0 as identity provider and the current options fall short for our use case.

[frederikprijck]

Thanks for reporting.

To try and understand this, why is the country picker acting as the OIDC server? From what I understand it isn't an actual OIDC server but you are trying to use it as such by making it OIDC compliant and then forcing our SDK to go to that URL instead.

Is there a reason you can not have Auth0 be integrated in the country picker and use any of our SDKs from there?

You could also try and leverage Auth0 Actions, to redirect to the country picker when there is no country query param available, and redirect back to Auth0 once a country is selected.

I don't think we should make the authorization URL configurable to be able to navigate to an OIDC server that really isn't one, instead, we should look into a solution that allows for your use case. For that, I recommend reaching out to your Account Manager and take it from there as a first step to see if our Solution Engineers (or architects) have a better idea how it fits in Auth0.

I believe it's worth looking into other directions as I think it should be achievable using the SDK in its current state.

[frederikprijck]

We had a conversation internally, and we believe we can not accommodate for this request.

You may be using auth0, but "The country picker page is hosted on a separate domain and is OIDC compliant." acts as a third-party identity provider.

Apart from the solutions mentioned above, you might be able to :

• login to Auth0 from the country picker page
• After logging in to auth0 from the country picker page - redirect back to the application
• Then immediately login with prompt=none to auth0 (where they should have a session)
• At which point they'll be redirected back to their application to complete the login

It's a couple of extra hops, but to the user the experience will be the same.

However, as mentioned, this is stuff that Solution Engineers or Architects can provide better help with, which you can contact through your account manager.

Closing, as this isn't something we should action.

[arjenvanderende]

Hi @frederikprijck,

Thanks for the quick reply.

You could also try and leverage Auth0 Actions, to redirect to the country picker when there is no country query param available, and redirect back to Auth0 once a country is selected.

As far as I can tell, Auth0 actions does not offer a pre login hook that we can use to customize the page before a user is presented with the login form.

login to Auth0 from the country picker page

The country picker does not host a login page. The only thing the country picker page does is forward a user to the Auth0 /authorize endpoint with the connection parameter tailored to the selected country. Auth0 does not offer any way to select the correct database connection from the hosted login page itself.

However, as mentioned, this is stuff that Solution Engineers or Architects can provide better help with, which you can contact through your account manager.

Last time we checked with our account manager, they were not able to offer any other solution than the country picker page we currently implement. We will check again, but our understanding is that Auth0 does not offer any solution out-of-the-box for our use case.

[frederikprijck]

As far as I can tell, Auth0 actions does not offer a pre login hook that we can use to customize the page before a user is presented with the login form.

I was refering to the pre-registration, but that may not work depending on your use case.

The country picker does not host a login page.

What I mean with login to Auth0 is to trigger the redirect to Auth0 using any of our SDKs from that page, and not have our SDK think your page is Auth0 (as mentioned here).

Last time we checked with our account manager, they were not able to offer any other solution than the country picker page we currently implement. We will check again, but our understanding is that Auth0 does not offer any solution out-of-the-box for our use case.

I don't think we offer anything out-of-the-box, but I don't see why you can not implement what you need without making our SDK believe your custom page is the IDP, as it isn't.

I recommend looking into the solution mentioned here.

I would think it'd come down to something along the lines of:

• Host the country page on country.yourdomain.com
• Host your application on app.yourdomain.com
• Logging in on app.yourdomain.com means redirecting to country.yourdomain.com, outside of our SDK. This page serves as your login page, not an OIDC-compliant IDP. Ensure you pass the required information from any app to the login subdomain.
• Have country.yourdomain.com do its thing, and eventually use our SPA-JS SDKs to actually log in to Auth0 by calling loginWithRedirect (ensure to set the cookieDomain to ensure the authentication hint cookie is put on .yourdomain.com, see https://auth0.github.io/auth0-spa-js/interfaces/Auth0ClientOptions.html#cookieDomain). You also want to set the authorizationParams.redirect_uri to something like country.yourdomain.com/callback and handle the callback there.
• Once the user is logged in on country.yourdomain.com, redirect back to app.yourdomain.com/callback, and on the callback path call our SPA-JS SDK loginWithRedirect, and set authorizationParams.prompt to none, and the authorizationParams.redirect_uri to app.yourdomain.com/callback2. This should reuse the session on Auth0 as it was set from country.yourdomain.com. be sure to, again, handle the callback.

I'm not a solutions engineer or architect, so take this as an idea and not a guaranteed solution. But that's the path I'd look into together with the Account Manager and/or Solutions Engineer / Architect.

[frederikprijck]

Hey @arjenvanderende

Came to think about the fact that you can do the following:

loginWithRedirect({
  openUrl(url) {
    window.location.assign = url.replace('customer.auth0.com/authorize', '...');
  }
})

Even though this still doesn't mean we support third party IDPs, I believe it should work if all you want to do is send them to your URL on interactively login.

Note that any other calls (e.g. getTokenSilently) will not be sent to your URL, but if I understand your use-case, that should help you achieve what u want.

Would that help?

[arjenvanderende]

Hi @frederikprijck

I really appreciate the thought you have given this.

Even though this still doesn't mean we support third party IDPs, I believe it should work if all you want to do is send them to your URL on interactively login.

Note that any other calls (e.g. getTokenSilently) will not be sent to your URL, but if I understand your use-case, that should help you achieve what u want.

I expect this will do exactly what we want/need. Only the interactive login calls need to be forwarded to the country picker; other calls like getTokenSilently are fine on the Auth0 domain.

I'll look into testing this suggestion to see if it works for us. In case we have any more questions, we'll reach out to our account manager. Thanks for your suggestions.