User experience considerations for Single Sign-On.
When SSO is enabled, the sign-in experience requires thoughtful UX design to guide users through authentication smoothly. There are several approaches an application can take:
Throughout this guide, consider the following scenario:
This document offers guidance on UX best practices when integrating SSO with the standalone API. You might instead consider WorkOS AuthKit, a complete authentication platform which handles all of the UX complexity for you.
A basic approach is to create a link or button on the login page with a Sign in with SSO or Use Single Sign-On option. This method differentiates the flows for the user explicitly.
The application can still look up the domain if a user tries to sign in with their corporate email and redirect them to the appropriate flow – see the demo below as an example.
Try signing with credentials, then using Single Sign-On with any @foo-corp.com email.
As this adds yet another button, one thing to be mindful with this approach is the NASCAR problem where a cluster of 3rd party branded buttons creates both visual noise and confusion. Consider only offering a couple of options that are relevant to your user base.
Instead of asking users for their email and password in one screen, the application first asks for their email. This method provides an opportunity to check if a particular domain is SSO-enabled and redirect the user to the appropriate SSO flow. It is a popular approach employed by many applications, including WorkOS itself, Apple, and Google.
Try signing in with any @foo-corp.com email vs. credentials.
As an extension to the previous approach, the application can automatically hide the password field if the user’s domain is SSO-enabled. This technique is more involved to implement, but provides a more seamless experience for users.
Try signing in with any @foo-corp.com email vs. credentials.