SaaS authentication: the best method(s) to use for your app

As you build your SaaS app, sooner or later, you’ll have to pick a user authentication method. But with so many options out there — like the classic email/password authentication, social and SSO logins, and even MFA and magic links — how do you decide?

Well, it depends on the app you’re building. Is it an enterprise or a consumer one? How secure should it be? Is it a multi-tenant or a single-tenant app? How much time do you have to add authentication?

In this article, we’ll talk about the various SaaS authentication methods you can use, how they work, their use cases, and what to keep in mind before you choose an authentication method(s) for your app.

What is SaaS authentication?

Authentication is the process of confirming a user’s identity before allowing them access. SaaS authentication is the same as normal authentication just that users are verified before accessing SaaS apps.

There are several SaaS authentication methods. They include:

• Email/password: Uses emails and passwords.
• Social Logins: Uses social media accounts like GitHub or Google to log in users.
• Magic Links: Uses unique login links sent to the user’s email.
• MFA (Multi-factor Authentication): Uses a combination of authentication methods like passwords and SMS codes.
• SSO (Single Sign-On): Allows users to log in to multiple apps at the same time without logging in to each of them individually, often with a corporate account.

What to keep in mind when choosing a SaaS authentication method

Before you choose an authentication method for your SaaS app, there’s a few things you’ll want to keep in mind.

How long will it take to implement?

Some methods like email/password authentication and social logins are relatively quick to set up, while others like SSO can take weeks or months to fully integrate. Think about your team’s bandwidth and how soon you want to launch.

How secure does it need to be?

If you’re handling sensitive or heavily regulated data, you may not have enough time and knowledge to build a secure authentication system.

You’ll need to stay up-to-date with changing data regulations and privacy laws, and conduct regular security audits, and updates to address any vulnerabilities. You might even be required to take on certain ISO certifications (such as the ISO/IEC 27001) to prove your commitment to data security or hire a dedicated team of security and compliance experts.

What do your customers need?

Large organizations will likely require SSO to automatically provision users to your app. Individual users may prefer the convenience of social logins or magic links. Do your research and find out what your users like.

Are you building a single or multi-tenant app?

Multi-tenant apps serve multiple users or organizations per account, to support team logins for example. A smart and future-proofed choice here is SSO with role-based access control — after a user logs in, they get access rights tailored to their specific role.

For single-tenant apps, each app instance is dedicated to one user so security risks are lower. You have more flexibility in the authentication method you choose to use.

Popular SaaS authentication methods

Below is a more in-depth list of the most popular methods used for SaaS authentication:

Email/password authentication

Email/password authentication is one of the most common ways of authenticating users in SaaS apps.

Here is how it works:

• When a user tries to log into your app, you redirect them to the page with the authentication form.
• The user enters their email and password and submits the form.
• Your app verifies the submitted details by checking them against a user database.
• If there’s a match, it grants the user access, if not it denies them.

Email/password authentication is quite easy to implement. You only need to get the email and password from the form and search for a match in your database.

However, it’s extremely insecure and very prone to hacking — passwords can be stolen or phished.

Use this form of authentication only when security is not a priority.

If you do decide to use it, do the following to reduce security risk:

• Always use HTTPS so user data remains encrypted during transit.
• Hash passwords before storing them.
• Require strong passwords (Relevant XKCD).
• Ask users to verify their emails before allowing app access.
• Combine it with MFA. For example, ask users to enter a one-time code sent to their phone or email after logging in with their passwords.

Single Sign-On (SSO)

SSO, or single sign-on, allows users to authenticate once and access multiple SaaS apps. It’s commonly used by organizations to give their employees access to multiple apps through their corporate identity provider.

Adding SSO support to your app benefits both you and your users.

SSO allows you to offload the burden of verifying and authenticating users’ identities to the identity provider which means less work for you.

For users, SSO means convenience — they only have to log in once they sign in to the SaaS apps they use.

If you’re building an enterprise SaaS app, SSO means more sales. Enterprises rely on SSO to manage the hundreds (or more) employees that use all the SaaS apps used within the company. For them, SSO means less time spent managing access and is a precursor to closing almost any enterprise deal.

SSO uses authentication protocols like OIDC (OpenID Connect) and SAML (Security Assertion Markup Language) which dictate how users should be authenticated and how identity data should be transmitted.

Here’s how you implement SSO in your app:

• Choose the IdP your customer uses from the list of integrations WorkOS provides and follow the instructions to configure an SSO connection. If you don’t find the IdP, you can create a custom connection.
• Install the WorkOS SDK compatible with the programming language you’re using.
• Create an endpoint in your application to initiate SSO using the WorkOS API.
• Set up the endpoint in your application where users will be redirected after being authenticated by their IdP.
• Configure the endpoint in your WorkOS dashboard to sign in users.

For detailed step-by-step instructions, refer to the WorkOS docs on adding SSO to your app using the WorkOS SSO API.

Compared to methods like email/password authentication, SSO authentication requires a significant investment in development time and resources especially if you’re supporting multiple IdPs (which is not unusual) — they handle SSO in slightly different ways and you often end up needing custom integrations for each. The benefits for both you and your customers, however, make the effort well worth it.

Social logins

Social login is a very popular authentication method among non-enterprise SaaS apps. This method allows users to use their existing social accounts such as Google, Facebook, and GitHub to sign in.

Social logins usually use both the OAuth and OIDC protocols.

OAuth allows users to grant access to their data on one service to your SaaS app without sharing their logins. It works through access tokens like this:

• When a user wants to authorize access, your app redirects them to an authorization server (like Google or Facebook) to login and approve the request.
• If the user grants your app permission to access their data, the authorization server redirects them back to your app with an access token.
• You can then use this token to access resources on behalf of the user.

To get the user’s data when they log in, you’d have to use the OIDC protocol instead. OIDC extends the OAuth protocol, and instead of just getting an access token, you also get an ID token that contains user info like their name and email address, which you can use to create an account for the user in your app.

Some of the main benefits of social authentication for SaaS apps are:

• It’s easy to implement: Most major providers like Google, Apple, and GitHub provide SDKs and step-by-step docs that’ll get you started quickly.
• It’s secure: Users can revoke your app’s access whenever they want.
• It’s familiar to users: Many people already have Google, Facebook, etc. accounts so they’re familiar with the login flow.

If you’re building a consumer app, social logins are all but mandatory. Most users have social media accounts and are used to logging into third-party services with these accounts. They’ll expect your app to have a “Login with social” option too.

However, keep in mind not everyone will want to connect their social accounts with your app. You may want to offer these users another alternative login method like a traditional email/password login.

Magic links

Magic links authentication, sometimes called passwordless authentication, involves sending a unique, single-use “magic link” URL to the user via email. When the user clicks the link, they are automatically logged in to your app.

Here’s how it works:

• When the user needs to log in, you ask them to enter their email on a login page.
• You generate a random string of characters for the user as a token and store it in the user’s account record.
• Then, you send them an email with a link containing that token.
• When the user clicks that link, you extract that token from the URL, look up the user account associated with that token, and log the user in by setting a session cookie.
• You can then invalidate that token to prevent it from being used again.

Magic links work great for:

• SaaS apps where convenience is a priority: Customers can access your app quickly without fussing over a password.
• Apps where security risks are low: Since there are no passwords, a bad actor could intercept a link and use it to log in to the app. You can combine magic links with multi-factor authentication for higher-risk apps.
• User onboarding flows: Magic links provide an easy way for users to create an account and log in for the first time. You can collect the email, generate a login link, and get them into your app quickly.

Users need to have access to their email to use magic link authentication. So, you may want to combine it with another login method for the times that they don’t.

Multi-factor authentication

Multi-factor authentication (MFA) is an authentication method that requires users to use more than one verification method to log in to a SaaS app.

The most common MFA methods are:

• One-time passcode (OTP): Your app sends a one-time passcode (OTP) to the user via SMS or email. The user must enter the code to log in.
• Time-based one-time passcode (TOTP): Your user’s authenticator app like Authy or Google Authenticator is linked to your app and generates a temporary code that changes after a short time. A user must enter this code in your app to log in. TOTP is more secure compared to text or email-based codes — they require the user’s device and the codes change often.
• App-based push notifications: The app sends a push notification to the user’s phone asking them to approve or deny the login request. Only when the user approves, do they get access.
• Passkeys: The use of fingerprints, face IDs, or other biometrics as an additional verification method.
• Backup codes: These are single-use codes that can be used if other MFA methods are unavailable e.g. when they lose access to their authenticator app.

MFA is great for high-security apps. Use it if your app deals with sensitive data.

However, note that MFA can be frustrating for some users. You may want to stick to only two to three authentication methods.

How to implement SaaS authentication

It’s very common to offer users multiple authentication options. And, while it boosts user experience, it requires a significant number of engineering man hours to implement multiple authentication flows that are not only error-free but also secure.

You’ll need to juggle both the unique setup demands for each method and the different security best practices, all while keeping up to date with the varying policies and APIs of the providers you’re integrating with.

A more efficient alternative is to use a platform like WorkOS which gives you a complete user management system with authentication and security features fit for single users or enterprise customers.

It supports all the authentication methods mentioned in this article, including:

• Email/Password authentication with features for verifying emails and resetting passwords.
• Single Sign-On for popular identity providers like Okta, Azure AD, and Google Workspace custom SSO connections, for IdPs that use SAML or OIDC protocols.
• Multi-factor authentication with an authenticator app that supports one-time passcodes.
• Social Login for OAuth providers such as Google, Microsoft, and GitHub.
• Magic Auth by sending a unique one-time-use code to the user's email.

An easy way to integrate WorkOS User Management into your SaaS app is through AuthKit, a customizable sign-in UI that takes care of the entire authentication flow for you. It’s designed to handle every possible error and edge case across multiple identity providers.

To get started, you’ll need to:

• Sign up for a WorkOS account.
• Get your WorkOS API Key and Client ID, which you’ll store in your app as secrets.
• Install the WorkOS SDK for your programming language.
• Set a redirect URI in the WorkOS dashboard. This is the endpoint that WorkOS will redirect to after a user has authenticated.

When a user initiates a sign-in request, redirect them to the AuthKit URL. AuthKit will handle the authentication process before returning an authorization code to your app. Your app can then exchange the authorization code with an authenticated User object and create a session for that user.

AuthKit supports all the authentication methods available in WorkOS User Management which you can manage in your WorkOS dashboard.

If you’d prefer to build your own authentication UI instead of using AuthKit, use the User Management API.

Explore WorkOS User Management.