Can My App Support SSO and Password-based Logins?

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:

• The four common UI design patterns for offering both SSO and password-based logins
• Why it’s usually not a good idea to allow SSO users to also sign in with their email and password (unless they are admins!)
• The general implementation details for including both SSO and email/password combinations in your app’s login flow

What’s the difference between password-based logins and SSO?

Just to ensure we’re starting with the same vocabulary, let’s briefly define the two types of authentication this article is about:

• Password-based login: The traditional way of logging into a website using your email and password

• Single-Sign On (SSO): A method of authentication where a user’s identity is confirmed by an Identity Provider (IdP), and that confirmation is sent to your application. (Check out The Developer’s Guide to SSO for a more detailed explanation.)
• Social logins: A form of SSO offered by companies like Facebook, GitHub, etc.
  

Can I offer SSO and password-based logins for different types of customers?

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:

1. Give each of your SSO customers a different subdomain at which they login, and a main login page for non-SSO customers.
2. On the login page, provide a link or button for users to sign in with SSO instead of entering their email and password.
3. Accept an email input on the login webpage, and the next webpage either shows a password field or the SSO login initiation.
4. Create dynamic password fields that reveal or hide themselves depending on whether the user’s email domain is associated with an SSO connection. 

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.

Can I let SSO users also sign in with their email and password?

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.

How do I implement SSO in addition to password-based logins?

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. 

Two modes of authentication in the same app

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 support@workos.com and we’ll be happy to assist!