If you’re considering adding Single-Sign On (SSO) to your SaaS application, you’ve probably wondered if you’ll be able to offer SSO alongside your existing login system, which most likely uses a combination of an email address and password to authenticate users.
The short answer is “yes”, your app can support both SSO and password-based logins, as well as social logins which are a form of SSO. You can enforce SSO for your customers who require it and still allow non-SSO users to access their accounts with their email and password.
In this article, we’ll cover:
Just to ensure we’re starting with the same vocabulary, let’s briefly define the two types of authentication this article is about:
Yes! In fact, most SaaS products that offer SSO also offer regular email and password logins because customers who aren’t using SSO still need a way to access the product. There are four common design patterns for this:
If you want a deep dive into each of these design patterns, you can learn more in UI/UX Best Practices for IdP and SP-initiated SSO.
Technically, yes, but for security and audit reasons this is usually not advisable. Most SaaS products will restrict user authentication to only allow SSO once it’s been set up for an organization and its employees. There are many security benefits of enforcing SSO, so allowing users to circumvent it by logging in with an email and password defeats the purpose of offering SSO in the first place.
It is possible to allow SSO users with an admin role—however that’s defined for your product—to still sign in with an email and password. This is an “escape hatch” for the IT department in case they need to fix an issue with the SSO connection or recover login functionality if something breaks. Typically, IT admins have good “password hygiene” and are the ones enforcing digital security, so the escape hatch is permissible from a compliance perspective.
When shifting an organization’s users over to SSO from the more typical email and password login procedure, some SaaS products offer a grace period wherein both authentication strategies are allowable. This is useful if some kind of account linking or data migration is necessary. A more common technique, however, is called the “Big Bang”—all users are migrated to SSO and their passwords are simultaneously disabled. This immediate switch to SSO is usually the best approach from a security perspective.
Once you’ve decided to implement SSO in your app, the first step is to determine which approach you’ll use to integrate it. The next step is to choose one of the four common design patterns for offering both SSO and password-based logins, which are outlined above.
Regardless of which integration approach or design pattern you choose, you’ll need a way to obtain the user’s email domain on the frontend and check whether it is associated with an SSO connection on the backend.
Offering two ways for users to authenticate—both via SSO and the typical email/password login—is both possible and very common. There are a number of ways you can represent these choices in your app’s UI, and the one you choose will depend on your use case and your product’s design considerations
If you decide to offer SSO through an integration with WorkOS, reach out to us at [email protected] and we’ll be happy to assist!