UI/UX Best Practices for IdP & SP-Initiated SSO
This post explores UI/UX best practices for Identity Provider (IdP) and Service Provider (SP) initiated SSO flows, like subdomaining tenants and separating email and password screens.
To learn more about UX considerations visit: https://workos.com/docs/sso/ux/sign-in.
If you’ve used a web app in the last decade, you’ve probably signed in using Single Sign-On (SSO). Clicked “Sign in with Twitter” or built an integration to allow users to sign in with Google? That’s SSO. SSO is a popular authentication mechanism that’s enabled application developers to register and sign in users easily, while allowing users to use a single service for their identity. Implementing SSO enables users to sign in using their Google credentials rather than remembering passwords for another service.
While SSO authentication lowers the barrier to entry to your product, it also presents new user experiences as you start to consider the actual mechanics of signing into your application. The SSO handshake involves validation between two parties - the Identity Provider (e.g. Okta) and the service provider (e.g. your app). Enterprise users now have two unique flows to sign into your application - via an Identity Provider (IdP) initiated flow or via a Service Provider (SP) initiated flow.
IdP-initiated SSO
SSO Identity Providers typically offer an application marketplace / dashboard that shows an enterprise user all of the applications they have access to. For example, Okta offers a browser extension that provides a quick way to see and sign in to the applications you have access to. IdP-initiated sign on is when an enterprise user clicks on your application from one of these places. The sign-on is initiated by the IdP provider, hence it’s called “IdP-initiated SSO.”
A Service Provider cannot solely rely on IdP-initiated sign on for users to access their application. Some Identity Providers don’t support IdP-initiated sign on and some app developers don’t build in the ability to use IdP-initiated sign on. On the other hand, consider the user experience of enterprise users who come directly to your website wanting to use your application. Only allowing IdP-initiated SSO requires users to always go through their Identity Provider dashboard, something users may forget.
SP-initiated SSO
Service Provider initiated sign on is when an enterprise user signs in by visiting an application’s website directly. If you decide to allow your enterprise users to sign in to your application from your own website, you can use ConnectionId or OrganizationId to map the user to the enterprise. There are a few different approaches to Service Provider initiated sign on that we commonly see utilized by applications:
- Subdomain your tenants
- Signing in with SSO
- Separating the email and password fields
- Dynamic password fields
1. Subdomain your tenants
One approach you can take would be to serve your application at a subdomain per tenant / enterprise. Slack is one web application that does this. When you visit slack.com and click on the Sign In button, you’re taken to this page:
If we consider WorkOS here, a WorkOS employee would enter `workos` into the input, Slack looks up what sign in options are allowed for `workos`, and on the next page offers the user the various methods their organization may use for signing in.
2. Sign in with SSO
A second approach would be to put a link or button on your login page for `Sign in with SSO`. One thing to remember is the NASCAR Problem - where a cluster of 3rd party branded buttons creates both visual noise and confusion on behalf of the user.
Cypress takes this approach, but is careful to only offer a couple of sign in options that are relevant to their user base:
Clicking the Single Sign-On link takes you here:
3. Separate email / password fields
Take a look at the initial login screens of two of the world’s largest tech companies. Notice anything missing?
They separate the login process into multiple steps or pages. When signing into Apple’s developer portal, it first asks only for your email then your password, because between the steps, Apple is doing a lookup to see if your domain is SSO-enabled. If it is SSO-enabled, instead of showing your password, it will take you though the SSO flow instead. Here at WorkOS, we even use it for our login page.
4. Dynamically hide the password field
An extension to the previous approach is dynamically hiding the password field - but only for domains which have SSO enabled. This is a bit more complicated to implement, but it provides a nicer and more “unified” user experience. An example of this style is implemented on the Dropbox login form.
Dropbox has implemented SSO, but that’s not immediately apparent from their login screen. As a user, for example `marc@salesforce.com`, types their email into the respective field, a search is being executed on the backend on every keypress to check if a matching SSO-enabled domain exists. Once a match is found, the password experience is replaced with the `Single sign-on enabled flow`. Now, the user just clicks `Continue` to sign in.
In our opinion, this is the smoothest SSO UI/UX, but again, we understand it’s more work to implement and test.
The SSO journey doesn’t end here
Adding SSO doesn’t mean you can get rid of usernames and passwords altogether. Users without SSO-based login still need some way to access your product. Even with SSO-enabled accounts, admin users need to be able to login using username / password so they can configure SSO for all users or get into the system in the event SSO isn’t working.
Your login page is the gate to your application, and it’s important to make it a polished experienced. A third-party service like WorkOS can help you build it faster so you can focus on the details.