What are differences between SAML and OIDC?

In this article, we provide an overview of the SAML and OIDC protocols, along with their typical authentication flows. We compare the distinct differences, pros and cons of each protocol. Additionally, based on potential user scenarios, we offer guidance on choosing between these two protocols.
Darcy Ye
Darcy YeDeveloper
December 13, 20235 min read
What are differences between SAML and OIDC?

OpenID Connect (OIDC) and Security Assertion Markup Language (SAML) are authentication protocols that allow Identity Providers (IdPs) to implement user authentication and access control. Each protocol defines its own mechanism for maintaining the identity of authenticated users, which is then used to grant or deny access to protected applications.

What are SAML and OIDC?

IdPs maintain databases of user identity information. Service Providers (SPs) rely on this information to authenticate users, sometimes enabling a single authentication to be used across multiple applications (single sign-on). OIDC and SAML are standards that define how this user identity-related information flows between these two parties. Their ultimate goal is the same: user authentication. However, the fundamental approaches they take to achieve this goal differ.

SAML

SAML 2.0, since 2005, is the current version of the standard. It uses XML to format identity information, requests and responses. XML is a mature standard for formatting documents in a way that is understandable by both humans and computers. To transmit or receive XML-encoded information, it uses basic SOAP or HTTP requests. Defined by the SAML protocol, the service requesting identity information is Service Provider (SP).

Before we introduce the typical SAML authentication process, we need to understand the elements upon which SAML authentication relies. Before IdP and SP can recognize each other and complete the authentication process, they need to "exchange" necessary information, usually accomplished through XML-formatted metadata. The exchanged information includes:

  • Public keys, with IdP and SP generating their own private and public key pairs and exchanging them to sign or encrypt communications. With advancements in network communication security, most scenarios now only require signing of requests, omitting the encryption step.
  • Endpoints, used for the SP to send SAML authentication requests to the IdP and for the SP to receive SAML assertions in response to authentication requests from the IdP.
  • Supported XML attribute formats, used for the IdP to transmit the required user information to the SP after completing authentication.

Once IdP and SP are aware of the aforementioned information, they can proceed with the authorization process (a typical SP-initiated authentication flow):

Identity provider (IdP)Service provider (SP)UserIdentity provider (IdP)Service provider (SP)UserUser not authenticatedValidate user identityVerify SAML assertionTry to access serviceRedirect to IdPSAML authentication requestAuthentication succeedSend SAML assertionHandle assertion and extract user identityAuthenticated

OIDC

OIDC is a contemporary protocol that enhances the OAuth 2.0 framework. It employs JSON-based Web Tokens (JWT) for constructing data payloads. JWTs, an established industry norm, set guidelines for the secure exchange and representation of claims between entities. These claims, essentially encrypted user data, are crucial for identity verification and management. OIDC primarily uses the ubiquitous HTTPS for data transmission.

As is widely acknowledged, the OIDC protocol supports a variety of different flows, including the authorization code flow, implicit flow, and hybrid flow. In the following example, we will go through the most secure and typical of these: the authorization code flow. This is also the flow utilized by Logto.

Resource OwnerAuthorization ServerClientUserResource OwnerAuthorization ServerClientUserAuthorization code flowClient init flowRedirect user to authorization endpointPrompt for authenticationUser authenticatesAuthorization codeRequest token with authorization codeReturn access token (optional refresh token)Can access user info with access tokenUser info

Distinctive aspects of OIDC and SAML

  • Given its more recent development, OIDC is better suited for modern application authentication compared to the older SAML standard.
  • Historically, SAML predates OIDC and has been integrated into numerous established corporate systems.
  • In contrast to SAML’s bulkier XML documents, OIDC's JWTs are compact and more user-friendly in processing.
  • Configuring OIDC is generally more straightforward than SAML.
  • A key feature of OIDC is its definition of “scopes”, allowing IdPs to manage a variety of permissions. Applications can request specific permissions from IdPs, which are granted upon user approval. This attribute of OIDC offers IdPs granular control over permissions.

How should one choose between OIDC and SAML?

Both OIDC and SAML are robust authentication systems, each with its unique strengths. The choice depends on your organization's specific requirements.

  • For quick and efficient identity platform deployment, OIDC is preferable over SAML. Implementing OIDC is simpler, avoiding the complex XML handling that SAML requires for metadata parsing, authentication request processing, and SAML assertion analysis.
  • OIDC is ideal for environments with extensive API interactions and sophisticated permission mechanisms, offering more adaptable and efficient control over permissions and a superior developer experience.
  • When integrating with established systems that are SAML-based, choosing SAML ensures smoother system interoperability and reduces the effort needed to bridge different protocols.

Are there good solutions available in the market?

Logto, a popular identity solution among developers, has recently introduced Enterprise SSO functionality. It offers support for both SAML and OIDC protocols, along with out-of-the-box integrations for mainstream IdPs like Google Workspace and Microsoft Entra ID (formerly Azure AD). With Logto, you can bypass the complexities of implement SSO on your own. A few simple configuration steps enable SSO support in your identity system, allowing you to select the appropriate protocol to meet your business needs.