We have enabled Single Sign-On for an organization using ADFS that we are working with via an enterprise SAML connection. In this particular scenario, the organization hosts a SAML identity provider, and we have enabled Auth0 as a service provider. Unfortunately, we are experiencing a problem where two users using our web application in the same browser session can result in the second user logging in as the first user. Here’s the workflow:
- User #1 enters his/her email in to the Auth0 Lock in our application that ends in “ssodomain.org”. The “Single Sign-On Enabled” message appears.
- User #1 gets redirected to the organization’s SAML login site.
- User #1 authenticates, and gets redirected back to our application.
- User #1 logs out of our application and leaves the browser on the login page.
- User #2, using the same browser session as User #1, enters his/her email that ends in “ssodomain.org”. The “Single Sign-On Enabled” message appears.
- User #2, gets redirected to the organization’s SAML login site.
- The organization’s SAML login site detects a pre-existing valid cookie (or some other local browser-based persistence) for User #1, automatically uses that for authentication, then immediately redirects User #2 back to our application without giving User #2 a chance to address this.
- User #2 is now logged into our application as User #1. (Gah!)
For clarity, the logout on Step #4 is an “application session” logout as described in the Auth0 Logout documentation. If we swapped this logout to be of type “Auth0 session,” would that allow the second user an opportunity to log in as him or herself? Is this something that needs to be changed as part of our SAML connection configuration with this organization, or something the organization should be changing on their end? We are confident that the “Identity Provider session” logout will allow the second user to login, but we consider that to have a poor user experience.
We took a stab at solving this by performing an “Identity Provider session” logout for all SSO users by setting the
federated parameter into a logout call to Auth0. Expectedly, that drove our testers crazy. Kicking them out of other web applications backed by that IdP session was a very frustrating user experience.