SSO protocols: SAML vs. OIDC

Welcome back to B2B Auth School. Our mission is to help B2B companies’ uplevel their understanding and implementation of authentication technologies. Our first series of posts is dedicated to single sign on (SSO). This article is lesson four in that series.

Lesson one | Introducing B2B Auth School
Lesson two | Organization tenancy: the foundation of SSO and B2B data models
Lesson three | What is single sign on?
Lesson four | SSO protocols: SAML vs. OIDC
Lesson five | What is OpenID Connect (OIDC)?
Lesson six | What is SAML and how does it work?
Lesson seven | Choosing a B2B auth provider

In the previous lesson we explained what single sign on is, and how it works between its essential components – service provider (SP), identity provider (IdP), auth provider, and the customer. We also diagramed full SSO auth sequences, like SP-initiated vs IdP-initiated, to demonstrate the number of actions and steps involved. The key takeaway? For SSO to function, all of its components must be able to communicate with each other efficiently and securely. This exchange of auth information between services occurs over something called protocols.

In this blog post, we’ll go over:

• What is SAML (Security Assertion Markup Language) and OIDC (OpenID Connect)
• How SAML-SSO and OIDC-SSO works
• The key SAML-SSO and OIDC-SSO flows
• The key differences between SAML and OIDC
• Why B2B SaaS vendors need to support both identity protocols

Let’s dive in

As a developer, you’ve probably had to build some form of user authentication functionality at work or in your side projects.

Whether you’re building an enterprise solution or a consumer-facing app, Single Sign-On (SSO) has become a key feature for implementing authentication without compromising security and UX. However, when it comes to choosing between SAML and OIDC, things can get confusing really fast, especially if you’re looking at the official specs.

SAML and OIDC are open SSO protocols that enable end users to access multiple applications without providing unique login credentials across these disparate systems. SAML is typically used by large enterprise organizations, B2B SaaS providers, government agencies, and high-grade security systems, while OIDC is commonly used in mobile and single-page applications (SPAs).

This article aims to clarify the core concepts, auth flows, and use cases of SAML (Security Assertion Markup Language) and OIDC (OpenID Connect). We’ll explore how each protocol works, their key differences, and when to use one over the other. By the end of this guide, you'll have a clear understanding of both protocols and be able to make informed decisions for your SSO implementation.

We'll start by diving into SAML, the XML-based protocol that has been a staple in enterprise environments for over two decades. Then, we'll explore OIDC, a more modern protocol built on top of OAuth 2.0 that’s gaining popularity in B2C and even B2B applications. We'll compare the structure of their assertions and scopes, discuss their interoperability, and highlight specific requirements for each.

What is SAML (Security Assertion Markup Language)?

SAML is an open identity protocol primarily used to implement SSO functionality within enterprise use cases. At its core, SAML SSO eliminates the need for employees to maintain unique credentials across all the intranet systems and SaaS applications they use for work. SAML achieves this by facilitating the exchange of authentication data between Identity Providers (IdPs) and Service Providers (SPs), according to SAML terminology.

Identity providers are the directories or data stores that organizations use to store and manage user profiles and identities within their companies, such as Entra ID, Okta, and Google Workspace. On the other hand, service providers are the internal systems or SaaS applications that employees use for their day-to-day work, such as GitHub, Linear, and Slack.

The basic SAML SSO flow is straightforward: When an employee needs to access an SP, they must first authenticate their IdP-provisioned credentials with the IdP used within their company. If their credentials are valid, the IdP sends an assertion to the SP, which then grants access to the employee without requesting additional credentials.

SAML uses XML (Extensible Markup Language) to structure user identity data and relies on HTTP or SOAP bindings to communicate this information between IdPs and SAML-enabled SPs. This user identity data is structured as attributes such as email, name, or department, and is enclosed in XML documents known as SAML assertions. In terms of security, SAML uses XML digital signatures and encryption to prevent tampering and unauthorized access to the SAML messages sent between IdPs and SPs via the protocol.

Here’s a sample structure of a SAML AuthnRequest in XML:

<samlp:AuthnRequest
    xmlns:saml="urn:oasis:names:tc:SAML:2.0assertion"
    Version="2.0"
    IssueInstant="2020-12-05T10:05:32z">
    <saml:Issuer Format="urn:oasis:names:SAML:2.0:nameid-format:entity">
        https://idp.example.org
    </saml:Issuer>
    <saml:Subject>
        <saml:NameID
            Format="urn:oasis:names:tc:SAML:1.1:name-id-format:emailAddress">
            fakeuser@example.com  
        </saml:NameID>
    </saml:Subject>
    <saml:AuthnStatement
         AuthnInstant="2020-12-05T10:05:32z">
         <saml:AuthnContext>
            <saml:AuthnContextClassRef>
               urn:oasis:names:tc:SAML:2.0:ac:classes:Password
               ProtectedTransport
            </saml:AuthnContextClassRef>
        </saml:AuthnContext>
    </samlAuthnStatement>
</samlpAuthnRequest>

How does SAML SSO work?

Before a service provider can successfully communicate with an identity provider in a SAML authentication flow, both parties must first establish a trusted relationship. This process requires the SP and IdP to exchange preliminary configuration details with each other using XML-based metadata.

This metadata typically contains details such as endpoint URLs where each party can post SAML messages—whether SAML requests in the case of the SP or SAML responses and assertions in the case of the IdP as the sending party.

It also includes the formats in which user attributes should be structured, signing and encryption certificates, supported connection methods, encryption algorithms, and other relevant details. Each party, both the IdP and SP, must use each other’s metadata file to configure their respective systems before trust can be established.

In addition to the SAML metadata, the SAML specification relies on four other key elements that make SAML SSO authentication possible. We have covered these core elements of the SAML protocol in a separate article, which you can find here.

SAML SSO flows

Once trust has been established between an IdP and SP, there are two major ways in which SAML SSO can successfully happen—the SP-initiated SSO flow and the IdP-initiated SSO flow.

In the SP-initiated SSO flow, the user must visit the SP’s login page, select the “Login with SAML SSO” option, and provide their work email for which pre-configuration must have been set. The SP would then send a signed SAML authentication request (AuthnRequest) to the IdP, and redirect the user to the IdP’s login page.

After the user authenticates their IdP-provisioned credentials, the IdP would have to generate a signed/encrypted SAML response containing assertions about the user and redirect them back to the SP’s endpoint. The SP would then verify the response, parse the assertions, and grant access if valid.

On the other hand, the IdP-initiated SSO flow offers a slightly different user experience. In this flow, there's no need for the SP to make an initial SAML AuthnRequest because the process begins at the IdP, not at the SP's login page.

In the IdP-initiated SSO flow, the user would begin at the IdP and select the SP from a list of SAML-enabled applications provided by the IdP. The IdP would then generate a SAML response and assertion and redirect the user to the SP’s URL endpoint. The SP would have to then validate the response and grant or deny access based on the assertions.

For a more detailed explanation of these SAML SSO flows, please refer to our comprehensive article here.

What is OIDC (OpenID Connect)?

OIDC is an open identity protocol that extends the core tenets of the OAuth 2.0 authorization framework by enabling OIDC-compliant systems to authenticate users in a simple but standardized and interoperable manner, without directly managing user credentials.

Unlike SAML, which is primarily tailored to enterprise environments, OpenID Connect (OIDC) can be used to implement SSO in both B2C and B2B scenarios. OIDC offers a more lightweight and flexible approach that's particularly well-suited for modern web and mobile applications.

The protocol facilitates single sign-on (SSO) by allowing end users to access multiple applications or websites (known as Clients or Relying Parties in OIDC terminology) using a single set of credentials managed by an OpenID Provider (OP).

These relying parties (RPs) can be any application or system that supports OIDC SSO, while Open ID providers (OPs) can be OIDC-enabled identity providers such as Okta, Google, Microsoft, or social media providers such as LinkedIn, Facebook, Twitter, or even other large platform applications like Slack or Discord. Open ID providers can also include security token services such as AWS STS or a typical OAuth 2.0 authorization server capable of issuing identity tokens, not just access tokens.

While OIDC is built on top of OAuth, it's important to note that OAuth 2.0 is an authorization protocol, not an authentication protocol. OAuth 2.0 is a framework for implementing delegated access/authorization, which enables clients to gain access to resources via an authorization/resource server on behalf of a resource owner.

For example, if you've ever granted permission to a third-party add-on to help take notes on your Google Meet or Zoom calls, or allowed an application like Buffer or TweetDeck to access your Twitter/X account and schedule tweets on your behalf, you've seen OAuth 2.0 in action. This differs from the standard OIDC authentication flow we've discussed so far.

How does the OIDC protocol and OIDC SSO work?

When a user attempts to log into an application (OIDC client) using an OIDC-SSO option, the client/RP has to redirect the user to the respective OpenID provider (OP) with an authentication request. The user then has to authenticate their OP-provisioned credentials with the OP. If the credentials are valid, the OP typically sends an identity token back to the client application in the form of a JSON Web Token (JWT).

This ID token contains authentication scopes similar to SAML assertions and includes claims/attributes about the authentication event and the user’s identity. These claims typically include the user’s unique identifier (sub), the time of authentication (iat), the issuer of the token (iss), and other relevant details needed by the OIDC client to make an authentication decision. The use of JSON web tokens (JWTs) in OIDC is what makes the protocol easier to implement than SAML, especially in RESTful architectures.

Here’s a sample structure of a JSON object:

{
    "url": "https://example.stytch.com/api/v1/oauth/tokens/",
    "id": "1c8ec5e4",
    "user_id": "8c794c21",
    "client_id": "2967031",
    "token": "gErypFlm4dOEg5MQ41nDo8so",
    "refresh_token": "yPfhqLoz9w5Bz2NA73tYs0ei",
    "created_at": "2022-12-05T10:14:32z",
    "expires_at": "2022-12-05T12:14:32z",
    "scopes": ["read", "write"]
}

There are five key elements (URLs) that collectively and securely work together to make OIDC SSO possible. These include the Discovery Endpoint, Authorization Endpoint, Token Endpoint, JWKS Endpoint, and UserInfo Endpoint.

The Discovery Endpoint provides metadata about the OpenID provider's configuration, allowing clients (Relying Parties) to access the necessary endpoints and capabilities of the OP. The Authorization Endpoint handles the user authentication request and returns an authorization code to the client. The Token Endpoint then exchanges this authorization code for access and ID tokens, with the ID token specifically carrying user identity information.

On the other hand, the JWKS Endpoint provides public keys for verifying token signatures, ensuring the integrity and authenticity of these tokens. Lastly, the UserInfo Endpoint supplies additional profile data about an authenticated user using the already-issued access token.

Just like is obtainable in SAML, the OIDC client (relying party) and the OpenID Provider (OP) must exchange some form of pre-configuration data before SSO communication can successfully take place.

Typically, the RP must register with the OP to be issued client credentials (such as a client ID and client secret) that it will use to authenticate itself when making requests to the OP’s endpoints. The RP also has to provide information about itself to the OP, such as redirect URIs and other necessary metadata.

In addition, the RP must request the OP’s Discovery Endpoint (usually at .well-known/openid-configuration) to access the OP’s JSON-based discovery document which contains relevant configuration details such as supported endpoints, scopes, and public keys.

OIDC SSO flows

At its core, OIDC supports three key authentication flows that define how RPs and OPs should communicate across different types of applications, including mobile apps, single-page applications (SPAs), and web-based apps. These flows include the Implicit Flow, Authorization Code Flow, and Hybrid Flow, which are tailored to meet unique UX and security requirements across these apps.

The Implicit Flow is suited for client-side applications like SPAs where tokens are returned directly to the RP in the redirect URI.

The Authorization Code Flow is more secure than the Implicit Flow and is best for server-side applications, as it securely exchanges authorization codes for tokens—tokens aren’t returned directly.

The Hybrid Flow combines elements from both the Authorization Code Flow and Implicit Flow. It allows the RP to receive an ID token directly in the initial response, alongside an authorization code that can be exchanged for access tokens.

SAML vs. OIDC: What are the major differences?

As we’ve established so far, SAML and OIDC are both widely used authentication protocols, but they cater to different needs and have distinct features. Here are four key differences between SAML and OIDC:

1. Authentication source: SAML relies strictly on IdP-based authentication, but OIDC relies on any OIDC-enabled authorization server (whether traditional IdPs, social media providers such as Facebook or LinkedIn, Security Token Services (STSs), etc.) to authenticate user identity.
2. Data format: SAML uses XML to structure identity data, making it inherently verbose and more complex to process. In contrast, OIDC relies on JSON which is a more lightweight and readable format widely used in modern RESTful architectures.
3. Security and message integrity: SAML relies on XML-based signatures and X.509 certificates to ensure message integrity and authenticity. Specifically, SAML uses XML Digital Signatures (XML-DSig) with signing algorithms such as RSA-SHA1 or RSA-SHA256 to sign SAML messages. OIDC, on the other hand, uses RSA or ECDSA algorithms with JSON Web Signatures (JWS) and JSON Web Keys (JWKS) for signing and verifying tokens.
4. Application use cases: SAML is primarily used for implementing SSO in browser-based applications across enterprise environments. However, OIDC extends beyond browser-based SSO to support authentication for APIs, microservices, mobile apps, web apps, single-page apps (SPAs), and even IOT devices.
5. Authentication vs. authorization: While both protocols handle authentication, their approaches to authorization differ. SAML can inherently handle both authentication and authorization by embedding access control data within SAML assertions. OIDC, on the other hand, primarily focuses on user authentication. However, it can be used in tandem with OAuth 2.0 to support authorization use cases.

Can SAML and OIDC be used interchangeably?

Most IdPs support both SAML-based and OIDC-based SSO protocols. As such, the choice between SAML and OIDC depends on your particular use case (whether B2B or B2C or B2B2C), the regulatory requirements in your industry, and your company’s internal security policies.

If you’re a consumer-facing application (B2C) you’re just fine supporting OIDC alone. However, if you’re an enterprise-facing application (B2B), you may need to support both SAML and OIDC to accommodate varying customer needs.

Auth providers like Stytch offer support for both OIDC and SAML, and SaaS providers who intend to implement SSO can use our SDKs and APIs to implement both protocols in weeks or even days.

This flexibility is particularly useful for SaaS applications that serve both startup customers that have less stringent security needs, and large enterprises, which may have robust access management requirements. In such cases, you can use Stytch to support social login via OIDC for these startups, while implementing SAML for enterprise organizations that may have higher security standards.

On the other hand, it’s important to note that many SaaS vendors may not allow their customers to use both protocols simultaneously. Most providers offer support for OIDC-SSO on their free and basic plans. As such, if you want to leverage SAML, these providers may force your organization to upgrade to their enterprise plan and migrate to using SAML alone, instead of using both protocols simultaneously.

Get started with SAML-SSO and OIDC-SSO using Stytch

Ready to implement single sign-on (SSO) using Stytch? Check out our backend integration guide and our frontend integration guide for SAML and OIDC-SSO.

Want to learn more about our APIs and SDKs? You can check our docs and sign up for a free developer account to start building today.

If you want to learn more about our Enterprise features and pricing, feel free to schedule a call with a member of our Solutions Engineering team.

Build auth with Stytch

Read the docs