Azure AD Enterprise Connection not working from Office365

Help
,
1

I am trying to set up SSO for a downstream customer who uses Azure AD (now Entra ID) so they can access our application through their Office 365 portal.

I followed the directions provided here

To test I registered an application in Azure in my own tenant, made it visible in my Office365. I set authentication for Web platform and used the login/callback from our Auth0 tenant.

In the Enterprise Connection, the Identity API is v2 and “always set email_verified” is set to false. I have not added any additional domains in Home Realm Discovery, and I’ve enabled our application.

When I test using Try from the Auth0 console it works, but when I try to connect through the Office 365 app, it redirects to the Auth0 login page. I expect that when I’m logged in to Office 365 and have SSO enabled that when I click on the app it will direct me to my application as a logged in user and I won’t need to log in again.

I also tried an OIDC connection following an Okta/Auth0 tutorial on youtube, but right now that app is failing to launch from Office 365 altogether.

Would appreciate any suggestions on where I’ve gone wrong with configuration.

2

In case anyone else comes across this post with a similar question, here is how we resolved it:

I got our Azure AD enterprise connection working, or realized that it was working but it does not show any sort of “Login With Microsoft” button. Rather, the login page will detect that the domain entered by the user is linked to an enterprise connection and redirect. We’re using Universal Login with customization, so the login flow was not immediately apparent, like it is with the Identifier First login flow. (The button is available if you turn off customization with Universal Login and use the Identifier First flow)

In order to create a “seamless” experience, I also tried to set up a SAML Enterprise Connection. This did eliminate the need for the user to login again, but introduces security risks related to “IdP-initiated” SSO, so we chose to stick wtih Azure AD rather than pursue the SAML option.