New to Auth0 but have been spending the better part of today just trying to get office 365 setup with SSO. I have managed to setup the connection, setup the SSO app, confirm the connection works. I then installed and configured the SSO dashboard extension and connected it to the 365 app and verified I can get to office 365 from that dashboard.
Now the problem I have is none of the logins other than the main management dashboard/console, whatever it’s called work.
Let’s say I try to login to the dashboard directly with the URL:
https://..webtask.run/auth0-sso-dashboard/login
It logs me in but then it loads to a blank page. This is the exact same URL that is resolved when I access this from the admin portal and navigate through the extension. I am the only user currently and set as an admin if that matters.
I have a similar issue when using Authenticating Profile, I set it to Identifier first, and when I use the same credentials I use when logging into the admin portal, it says invalid username or password. I have no idea what this auth is thinking here, there is one user that logs in fine from auth0’s website login but not my own account. I’m hoping these are both related to some unclear setting but right now, I’m stumped.
Just to make sure that we are on the same page, you have configured Auth0 as an IdP for your Office 365 dashboard, right?
From what I understand, since the SSO Dashboard is a separate application, not a part of the main Auth0 dashboard, when you are attempting to connect using the Office 365 SSO, it would be expected behaviour for your login process to succeed since you are already authenticated.
Why other logins may redirect you to an empty page might be because the URL used to access the dashboard directly is not configured as an Allowed Callback URL in the SSO dashboard and even if authentication is completed, the dashboard is not redirecting to the proper URL. For this, you would to go to Applications → Applications → SSO Application → Allowed Callback URLs. I believe the URL should look something like this:
Another cause is that the dashboard might be expecting a session cookie to exist, however, it is not present because the URL was accessed directly and not through the Auth0 Authentication flow.
Also, related to the issue where you are receiving an Invalid Username Or Password error, could you check your Auth0 Logs and let me know the details of the failed login? Is it using the expected connection or a different one? Additionally, can you please provide me through a DM the tenant name on which you have the SSO integration so I can check out your configuration?
I believe I found the issue here although I’m not sure I fully understand if this is the proper solution or expected workflow.
I had to go into my Office 365 SSO connection and click the “Display connection as a button” on the Login Experience.
If I tried to login to the tenant or main dashboard (still unclear about this), using this format: https://{TENANT_NAME}.{REGION}.auth0.com/u/login
I would be hit with an error leading me to this topic: https://auth0.com/docs/authenticate/login/auth0-universal-login/configure-default-login-routes Not sure the exact reason why there is no default landing page URL for your main tenant dashboard that can be hit directly and I wasn’t really sure what that doc was trying to describe as a solution or how it related to what I was trying to do so I ignored it essentially and found a different solution.
Using this format: https://{TENANT_NAME}.{REGION}.auth0.com/authorize?client_id={SSO_DASHBOARD_ID}&response_type=code&redirect_uri={SSO_DASHBOARD_LOGIN_URI}
Using the URL pattern from 3, this does load the proper Auth0 login experience with the SSO Office 365 option and loads the dashboard as expected. I assume using a landing page login URL of this complexity is not really the expected solution but this is so far the only way I have managed to get it to work. Maybe custom domains come into play to clean this up? Not really sure on that part of the puzzle yet.
Thanks for letting us know what the solution was for the issue at hand!
Indeed, Office 365 SSO connection can be quite weird to set up as most of the SSO connections would rely on an Microsoft AD connection. In your situation, it appears a default login route was required to be configured in order for the SSO connection to redirect to the proper page and everything should work as expected since the format looks good.
As you have mentioned, configuring custom domains would help in having a cleaner experience since you will be able to configure the domains for the specific routes.