How Single Sign-on (SSO) Works And Why You Should Care

Single sign-on (SSO) is a key part of any customer identity and access management (CIAM) strategy.

Why? Because your organization typically has more than one customer facing application. Even if you start with a custom application, SaaS tools such as support forums, ticketing systems, or chat require your customers to log in. SSO can minimize how many times a customer has to log in.

What Does SSO Mean?

SSO is an abbreviation for “single sign-on.” Integrating single sign-on into your applications means your users can access all their applications with one set of credentials. Those could be a username and password, a magic link, or a WebAuthn passkey.

Offering this allows you to have one view of the user, which is great for security and data consistency.

Single sign-on also allows users to minimize the time they spend getting into your application and maximize the time spent using it.

What Is An SSO Token?

Think of an SSO token as data that contains user-identifying information, such as a username or email address. When a user logs in through an SSO service, this token is created and stored either in the user’s browser or within the SSO service’s servers.

The token is then passed between systems during the SSO process to verify the user’s identity. This means that once a user is authenticated, they can seamlessly access other connected applications without having to log in again. The token is typically digitally signed to ensure it comes from a trusted source, adding an extra layer of security to the authentication process.

What Are the Benefits of SSO?

We’ve already uncovered some of these, such as an improved user experience. But let’s dive in deep with each of the benefits to see how they’ll impact your customer.

Enhanced Security

SSO reduces the risk of password-related security breaches by eliminating the need for users to remember and manage multiple credentials across different applications. It centralizes authentication, making phishing attacks less effective and minimizing the overall attack surface for cybercriminals.

Streamlined User Experience

With SSO, users only need to authenticate once to access multiple applications. This eliminates the need for repeated logins, reducing the brain burden associated with managing credentials. This streamlined experience can not only improve user satisfaction, your users might find greater productivity too.

Simplified Access Management

SSO solutions provide your team with better visibility and control over user access. Admins can manage user accounts, permissions, and access controls, from a single source making it easier to provision and remove users across multiple systems.

Regulatory Compliance

Centralized authentication and access controls in SSO help organizations meet regulatory requirements. Data access, user authentication, and audit trails are table stakes for FusionAuth. This makes HIPAA, SOC2, and other standards easier to manage.

Improved Productivity

Let’s say that you’re a business, creating an app that your employees will use to log in. As time goes on and you integrate more systems. allowing SSO lets people focus on their tasks rather than managing credentials.

Is SSO Secure?

Absolutely! SSO can be highly secure, but it needs to be implemented and managed correctly. Let’s break it down:

Centralized Security

SSO reduces the number of attack surfaces because users only login once, and with only a single set of credentials. In the rare case that a user account is compromised, that same centralized source allows you to remove the user once and mitigate the potential problems.

Reduced Password Fatigue

Users only need to remember one complex password instead of many. They’re then less likely to reuse passwords, or write them down.

Multi-Factor Authentication (MFA)

Most SSO solutions offer MFA as an extra layer of security. So even if a password is compromised, the bad actor still needs a second form of verification.

Vendor Security

Using a reputable SSO provider is crucial. They need to have a strong security track record, they’ll comply with industry standards, and they’ll make sure your data is secure. Always research and compare providers before making a decision.

Are There Different Types of SSO?

Yep! Each is designed to meet different needs and use cases. Here are some of the most common types:

SAML (Security Assertion Markup Language)

SAML is an XML-based protocol for exchanging auth data between an identity provider (IDP) and a service provider. You’ll commonly see SAML used in enterprise environments for web-based applications.

OAuth 2.0

OAuth is an open standard for access delegation. It’s commonly used for token-based auth. It allows users to grant third-party applications access to their resources, without sharing credentials.

OpenID Connect (OIDC)

OIDC is an authentication layer baked on top of OAuth 2.0. It uses JSON web tokens (JWTs) and it’s designed for consumer-facing apps. It’s a simpler and more modern approach to SSO compared to SAML.

Kerberos

Kerberos is a network auth protocol that uses secret-key cryptography to provide strong authentication for client-server applications. It’s most often used in on-premises environments, particularly within Windows domains.

LDAP (Lightweight Directory Access Protocol)

LDAP is often used in conjunction with other SSO protocols to provide a centralized authentication mechanism. It’s used for accessing and maintaining directory services over an IP network.

How Does SSO Work?

Let’s say you have two applications for which you want to enable single sign-on.

• The Pied Piper Video Chat application (PPVC)

• The Hooli Jobs application (they’re always hiring)

You want to let users log in to the PPVC, and then, if they visit Hooli to apply for a job, have them automatically signed in to the Hooli Jobs application. And you can have more than two applications behave this way.

This is single sign-on in a nutshell.

This pattern scales to any number of applications, and can include commercial off the shelf (COTS) apps that support OIDC (OpenID Connect) or SAML (Security Assertion Markup Language).

If you have a suite of applications, SSO can provide a seamless authentication experience for your users across the entire set of apps. A common suite of applications similar to this that you might have experienced is the Google suite. Gmail, Google Calendar, Google Drive and more all are entirely different applications running on different servers, but you can bounce between them without re-authentication.

But how does it actually work? This article will dive into this, but first, let’s talk about sessions.

How SSO Sessions Work

Sessions are how HTTP based servers “know” they’ve seen a client before. Sessions are typically implemented using cookies whenever the application is browser based.

In the SSO scenario above, the following sessions exist:

• The PPVC application’s session

• The Hooli Jobs application’s session

• The identity provider’s session

If a session doesn’t exist for a given application, or it isn’t valid, then the session must be created or updated. This happens after the user has presented valid credentials and been authenticated.

For the other applications in this example, the credential, which proves authentication has occurred, is a valid token.

Single Sign-on Request Flow

Here’s an OIDC single sign-on flow. The home page of each application is unavailable to anonymous users. When a browser requests it, they are directed to the identity provider to authenticate. However, the authentication at the identity provider happens only once.

Single sign-on request flow during login.

(If you are a stickler, you’ll notice there is no request for a token from the apps to the identity provider after the user authenticates. That is implied and required.)

With SSO there are different sessions managed by different applications, which can have varying lifetimes and storage mechanisms.

The PPVC and Hooli Jobs applications delegate authentication to the single sign-on provider, and build their sessions on the foundation of the identity provider’s session. That session is, in turn, tied to a user authentication event.

That’s it. All that is required for single sign-on to work is:

• a browser that respect redirects

• a single source of truth for user authentication data (often called an identity provider)

• a defined protocol for an application to bounce an unauthenticated user to the identity provider

• a defined protocol for the identity provider to bounce requests back to the application

• a sessions for each application (typically managed with cookies)

However, there are many use cases to consider, including:

• Account takeover

• Logout

• Account locking and revocation

• Loss of network access

Luckily, other folks have thought about these too, including standards bodies. Let’s look at another implementation, using a standard.

How SAML SSO Works

SAML is an alternative to OIDC which also allows single sign-on. It is older, more complex, but well supported across many applications, especially B2B applications.

(Again, if you’re a stickler, this is talking about SAMLv2, the latest version of SAML, codified in 2005.)

SAML, in contrast to the JWT based flow of OIDC, uses signed and/or encrypted XML documents to convey information about users.

Let’s look at a different scenario. Say you have two different applications: Zendesk and Gusto. You want to use SAML to integrate these applications with your identity provider.

Here’s a diagram for a SAML flow. This is a service provider (SP) initiated flow, where the user is trying to access an application, such as Zendesk (the SP), when they are not logged in.

SAML single sign-on request flow during login.

SAML is more complicated because of the breadth of the specification and because of the flexibility of XML. If you are looking to implement it, using a battle tested library is a good idea.

FusionAuth provides an open source library for Java that is regularly tested and updated.

Why Use SAML

Why would you pick SAML over the OIDC flow mentioned above? Widespread support. SAML has been around since 2005 and many commercial off the shelf and open source applications support it.

When evaluating your identity provider solution, think about what kinds of applications you need to support.

Any business focused applications will typically support SAML, whereas support for OIDC is far easier to implement in your custom applications. Newer COTS applications may support OIDC.

For maximum flexibility, pick an identity provider which supports both standards.

Beyond The Browser

Both SAML and OIDC are browser based. They require functionality such as HTTP redirects, cookies and the ability to interact using URLs.

There are other single sign-on protocols useful for other kinds of applications, such as desktop applications. Kerberos is a common one for client server applications.

Conclusion

Single sign-on is a key part of your application’s authentication story. Your users care about it, even if they don’t know it by name.

SSO doesn’t have to be difficult. Leveraging standards like OIDC and SAML helps you integrate both custom and commercial off the shelf applications with an identity provider.