We have a existing SSO connection setup under ‘Enterprise’ > OKTA Workforce but are moving over to Azure AD (Entra ID) as the identity provider.
The same ‘Email Suffix’ will be used. To move over would I need to delete the OKTA Connection > Add the Entra ID connection or can I have both running side by side as a “transition” until I am happy with how it works?
Hi @peter.cowen
Thank you for reaching out to us!
I understand that you currently have an Okta Workforce Enterprise Connection setup and wish to migrate to Azure AD (Entra ID) while retaining the Email suffix.
It is possible to have both the Okta and Entra ID Connections running side-by-side for a transition period and the Okta Connection does not need to be removed to set up the new one. Because both Connections will use the same Email suffix (domain), there is a specific way you must configure Auth0 to test the new connection without breaking the existing one.
Auth0 uses a feature called Home Realm Discovery (HRD) to automatically route users to the correct Identity Provider when they type in their email. By default, Auth0 can only route a specific email suffix to one connection automatically.
1. Set Up Entra ID (Without the Domain)
Add your new Azure AD (Entra ID) Enterprise Connection in Auth0. Crucially, do not map your email suffix (domain) to this new Connection yet. Leave the email suffix mapped exclusively to your existing Okta Connection so your regular users experience zero disruption.
2. Test the New Connection Explicitly
To test the Entra ID setup, you can bypass the Email suffix routing by explicitly telling Auth0 which Connection to use. You do this by passing a connection parameter in your login request and we warmly recommend our Knowledge Article on Authenticating Users Through a Specific Connection (database, social, etc.).
Depending on the Auth0 SDK you are using (like React, Angular, or standard web auth), you can trigger a login and append the parameter like this:
// Example using Auth0 SPA SDK
auth0.[...](asc_slot://start-slot-7)loginWithRedirect({
authorizationParams: {
connection: 'YOUR_NEW_ENTRA_CONNECTION_NAME'
}
});
This forces Auth0 to send you directly to the Entra ID login screen for testing, while everyone else continues to be routed to Okta via their email suffix .
3. Flip the Switch
Once you have tested Entra ID and are happy with how it works, you can cut over your users. Simply go into your Auth0 Dashboard:
Remove the email suffix from the Okta Connection.
Add the email suffix to the Entra ID Connection.
From that moment on, anyone typing their email will be routed to Entra ID instead of Okta.
Important mention: Watch out for User Duplication
When an existing user logs in through the new Entra ID connection for the first time, Auth0 will treat them as a brand new user because their Auth0 user_id will have a different prefix (generated by Entra ID instead of Okta).
To prevent users from losing their application profiles, permissions, or data, you will need to implement Account Linking. You can use an Auth0 Action (e.g., a “Post Login” Action) to automatically search for their existing Okta profile by email and link the new Entra ID identity to it.
We also recommend our Article on Multiple Enterprise Connections with the Same Home Realm Discovery Domain in Auth0 that offers additional information that can help achieve the derised flow.
Hope this helped, have a great one!
Gerald
Thank you for getting back to us. Potentially the changing the connection may not be an option but we can deal with that if we need to.
The duplicate users (the users in Auth0 just lets them login via SSO) are there any implications we need to be aware of
Hi @peter.cowen
Thank you for reaching back!
If the users are migrated to a new Connection where they use the same credentials to authenticate/login, the only difference would be that their user_id will change. If this does not affect their access within any application, then you should not be expecting any additional roadblocks along the way, however we do recommend running such changes in a testing environment first before deploying to production, just to observe what happens and overcomes any potential unexpected issues.
Have a great one!
Gerald