Dynamic login URL for SAMLP connection

I have a number of applications and a SAMLP connection that defers to Okta. The SAMLP connection is configured with a login URL that includes the Okta application ID. Okta does this to ensure that the person logging in has permissions to access that application. However, this login URL configuration is static, which means that I can only configure the connection to log in to a single application.

What I’d like to do is have the login URL be changed based on the Auth0 applications, which (more or less) are mirrored from Okta.

For instance, I have applications A and B in both Auth0 and Okta. When a person wants to log in to application A using their Okta credentials, the login URL they would be forwarded to is


But for application B, the URL would be different (e.g. my_application_b instead of my_application_a).

This way, I can manage user permissions in Okta through group membership which we already have set up.

Is this possible?

I’ve been playing around with adding multiple Okta connections, one for each application, and setting each application to only use its associated connection. However that has a side effect of creating multiple Auth0 users, one per person per application, which isn’t ideal. Secondarily, how will these duplicate accounts affect MAU?

1 Like

At first glance, beside the workaround with multiple connections I don’t think this would be possible as the SAML connection allows a single sign in URL and I’m not aware of any way to override it dynamically.

As an additional note, to your last question; the multiple connections will indeed have a pricing implication. From the end-user perspective you could consider account linking as a way to somewhat mitigate the user account duplication (https://auth0.com/docs/users/user-account-linking).

However, you would still need multiple enterprise connections which by itself may also pricing implications if I recall correctly.

1 Like

Can’t you send Okta group membership in the SAML tokens and enforce authorization in Auth0 instead? This is a more common pattern when using federation.

We are sending group membership, but we already have group-application authorization set up in Okta, and we’d like to reuse that without having to duplicate it in Auth0. Single source of truth is best.

I’m curious, why do you need Okta if you have Auth0 and all your applications have to be defined in both?

We started with Okta and only added Auth0 recently. It fits our business model to do it this way, but I can’t go into much more detail than that.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.