Can my app support SSO and password-based logins?

Are you considering adding Single Sign-On (SSO) to your SaaS app? You’re probably wondering if you can keep your existing password login system.

The good news is that you can absolutely support SSO and password-based logins. However, just because you can doesn’t always mean you should.

In this article, we’ll walk you through:

• A comparison of password logins vs SSO
• Four common UI design patterns for offering SSO and password-based logins
• Why allowing SSO users to also log in with passwords isn’t always a smart move
• Key implementation details for integrating both options in your app

Let’s start by looking at why a business might need passwords and SSO logins.

Why businesses need both password logins and SSO

A business might need passwords and SSO logins to accommodate different user needs. Not all users can access an Identity Provider (IdP) for SSO, so password logins ensure everyone can still access the app. 

What is SSO (Single Sign-On)?

SSO is an authentication method that uses a token-based system. It allows users to log in once via an IdP and transmits authentication tokens to grant access to multiple applications without needing further credential input.

Enterprises like how this centralizes user management and reduces password security risks. It can also be used with federated identities to enable access across multiple organizations or domains. 

Check out The Developer’s Guide to SSO for a more detailed explanation.

Password logins: Pros and cons

While newer methods like SSO are becoming more popular, password logins are still around for a few reasons:

• Simplicity: Email and password logins are familiar to everyone. It’s also straightforward for users and quick for developers to implement.
• Universality: Passwords work for all users, no matter their organization or setup. This versatility is why many SaaS apps still keep passwords in the mix — they’re an accessible option for customers who don’t need or want SSO.

However, most organizations are moving from passwords because of:

1. Security risks: Passwords are often the weak link in security. They’re vulnerable to phishing, brute-force attacks, and credential stuffing.
2. Management hassles: Users must remember unique, complex passwords for each account, which isn’t always easy. This often leads to bad habits like reusing passwords across sites, making accounts even more susceptible to breaches.
3. User friction: Password requirements are only getting stricter — longer, more complex, and regularly updated. While necessary, these requirements add friction for users, which can lead to more “forgot password” requests and higher support costs.

Password logins vs SSO: Key differences

Password logins are familiar to users but have risks like phishing and require users to manage multiple passwords. This can lead to password fatigue and more frequent resets.

SSO centralizes authentication through an IdP. It simplifies the login process by allowing users to access multiple apps with just one login.

For businesses, password logins are quick and cheap to set up. However, SSO offers better scalability and simplifies user management even though it might be costly.

How to support both password logins and SSO

Once you’ve decided to implement SSO in your app, the first step is determining which approach 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 below:

1. Give each SSO customer a different subdomain at which they log in and a central 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 following webpage will either show 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. 

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. 

If you want to examine each of these design patterns in depth, you can learn more about UI/UX Best Practices for IdP and SP-initiated SSO.

The benefits of offering both options

Below are some of the benefits of supporting SSO and password logins:

• Flexibility: Some customers, especially smaller organizations or individuals, may not have an IdP set up or prefer not to use SSO. Offering password logins alongside SSO makes your product accessible to a broader range of users.
• Admin escape hatch: Allowing SSO users with an admin role — or however that’s defined for your product — to still sign in with an email and password can serve as 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. 
• Transitional period: When shifting an organization’s users to SSO from the more typical password logins, some SaaS products offer a grace period where both authentication methods are allowed. This is useful if some 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. 

That said, offering both password and SSO login is usually not advisable for security and audit reasons. Most SaaS products will restrict user authentication to only allow SSO once it’s been set up for an organization and its employees.

Enforcing SSO has many security benefits, so allowing users to circumvent it by logging in with an email and password defeats the purpose of offering SSO in the first place. 

Instead of maintaining password logins for general users, consider implementing social logins as an alternative. Social logins, such as Google or Apple, act as a form of SSO, providing a familiar and user-friendly experience while still allowing some level of centralized management through OAuth protocols.

How WorkOS helps businesses support both login methods

Supporting both password logins and SSO doesn’t have to be disruptive.

With AuthKit by WorkOS, the customizable hosted sign-in UI, you can easily set up your app to support email/password logins, SSO, or both — choosing from popular IdPs like Okta, Microsoft Entra, and more without needing custom integrations.

If you prefer to build your UI, WorkOS’s authentication APIs are straightforward.

For enhanced security, WorkOS provides features like multi-factor authentication (MFA) and password validation, critical for strengthening identity management and reducing unauthorized access risks.

You can turn off passwords entirely if you prefer to restrict access exclusively to SSO-provisioned users.

Ready to get started? Explore User management by WorkOS - sign up today and start selling to enterprise customers tomorrow.