SAML vs. OpenID (OIDC)

There’s a small universe of identity and authentication protocols/standards, each with its own benefits and differences. This article explores how SAML and OpenID Connect (OIDC) compare, the scenarios where either protocol would be beneficial for your organization, and how each contributes to identity and access management (IAM). Each approach will enable single sign-on (SSO), but there are distinct technical and ideological differences to assess before you begin your project: SAML is more specialized toward securely granting website access across domains while OIDC provides additional context for mobile and web applications.

SAML vs. OpenID (OIDC) 

This article could simply offer a comparison between Security Assertion Markup Language (SAML 2.0) and OAuth (Open Authorization). OAuth is the foundation for OIDC, but OIDC extends the former with an identity layer to authenticate your existing user accounts using a decentralized service that’s operated by the not-for-profit OpenID Foundation. The open source community initiated OpenID’s development in 2005 with the objective that identities should be decentralized and not owned by a third party. There’s now over one billion OpenID-enabled user accounts from over 50,000 websites, according to the foundation. It’s the steward of the infrastructure that supports OIDC authentication, its community, and any legal or governance operations. 

SAML 2.0, on the other hand, is an open standard that has provided authentication and authorization between commercial and private identity providers (IdP) and service providers (SP) since 2003. It began as a way to implement SSO using an XML based framework to allow identity providers and services to exist separately from one another, with centralized user management. Let’s begin by examining how SAML works, exploring it component by component.

How SAML Works

SAML is an open standard for authentication (and authorization, if required) that provides SSO access to web applications through identity federation. SAML relays user credentials from an IdP that owns and maintains identities to verify access rights and SPs. Service providers require authentication prior to granting users access to the resource. Each user (or group) has attributes that outline profile information and assert what exactly they’re authorized to access.

SAML uses extensible markup language (XML) metadata documents (SAML tokens) for an assertion process to verify a user’s identity and access privileges.

Developers use SAML plugins within apps or resources for an SSO login experience that assures security practices are being followed and credentials/assertions determine who can access an application. Additionally, SAML can be used to control what resources an identity can access in an application. 

SAML is comprised of several core components that make it possible to exchange user information for access control, including IdP, client, attributes, to the SP. 

Identity Provider (IdP)

An IdP is a service that maintains and manages digital identities to verify user credentials throughout applications, networks, and web services. It’s primary role is to safeguard the integrity of user credentials and federate user identity where SSO logins are desired.

Client

Clients are your users who will authenticate into a service using the credentials that are being managed by an IdP. For example, your employer may use SAML for SSO access into the services that you need to work, using your company email address and password.

Attribute

SAML transfers messages, called assertions, from an IdP to a service provider. These assertions set all relevant security requirements for the transaction by authenticating, authorizing, and determining the level of permissions a client will receive. Attributes such as “dept,” “email,” and “role,” are used to enforce access management and access control. Sometimes, custom attributes are used so that SAML can be extended for use with custom software.

Service Provider (SP)

Service providers are a resource that users authenticate into using SAML SSO, usually a private website or application. They receive, accept, or deny assertions from IdPs for each client profile prior to granting users access. SPs send requests to IdPs to begin the authentication process, and the client’s assertion is received in response. The process is sometimes reversed when an IdP initiates the sign-in flow to assert user identity. It can be initiated either way.

How OIDC Works

OIDC extends the OAuth protocol so that client services (your applications) verify user identities and exchange profile information through OpenID providers via RESTful APIs that dispatch JSON web tokens (JWTs) to share information during the authentication process. The providers are essentially authentication servers. Many developers are attracted to this approach because it’s highly scalable, flexible across platforms, and is relatively simple to implement. Its main components are a unique user ID workflow with OAuth underpinnings.

User Authentication

A resource owner (your users) authenticates and is authorized to access a client application by way of an authorization server that grants an access token that allows apps to receive consented information from a UserInfo endpoint. A UserInfo endpoint is a protected resource found on an OpenID server that contains claims (assertions) about each user in a JSON object. Authentication information is then encoded within an ID Token that’s received by the app. This information is cached for scalable performance and personalizes the end-user experience.

Built on OAuth 2.0 Protocol

OIDC is built on top of the OAuth 2.0 framework, which is a standard that grants third-party apps and service access to user ID resources. No user credentials are sent over the wire or stored on third-party servers, which increases security and ease of use for IT administrators.

Similarities

• Both frameworks are identity protocols that make SSO possible.
• Both frameworks are secure, well-documented, and mature.
• Users authenticate via an IdP, typically once, and then can access other applications that “trust” the IdP. Some Zero Trust services will authenticate at each point down the chain and periodically verify access using another authentication method.
• The login workflow appears very similar to the end user, who doesn’t have any visibility into the various technical differences that occur behind the scenes.

Differences

• Many developers believe that OpenID Connect is simpler to implement because there’s no XML handling.
• OpenID lacks user authorization data (such as permissions) and focuses primarily on identity assertion. SAML is an identity data exchange and is very feature-rich.
• Authentication is decentralized with OpenID.
• SAML uses assertions versus the OpenID and OAuth architecture of ID tokens.
• OIDC is designed for API workloads and can be used to secure APIs.

Use Cases

Developers and IT organizations should select the solution that works best for their particular use case(s). However, it’s sometimes possible to utilize more than one simultaneously. Regardless, use cases have developed organically with OIDC being utilized for back channel web and mobile applications that request access tokens. 

SAML is nearly always used for front channel website access where users are the ones who are triggering the app to authenticate. The latter assumes that client applications (a web service) are operating from separate devices than the resource owner (you). Below are some general guidelines for use cases:

• A mobile app typically uses a service such as OIDC, because it’s lighter weight, and many of the facilities that developers use are pre-built or available from add-on libraries.
• Apps that have SAML built-in are a no-brainer, just use SAML.
• Use SAML for accessing enterprise apps via a portal.
• Protecting APIs or exposing APIs are services that will require OAuth 2.0 or OIDC.
• Enterprises sometimes favor SAML due to its capacity for customization and prioritization of secure data exchange. Regulated industries should almost always opt for SAML to protect sensitive user information.

Using OIDC and SAML Together

These protocols aren’t mutually exclusive. Consider using SAML for enterprise SSO to secure access to your organization’s resources and OIDC for mobile use cases that have high scalability requirements. Each has its own inherent advantages and either can provide SSO services.

Learn More

If you’d like to learn more about how to combine the best of both worlds, using SAML and OIDC, please contact us. The JumpCloud platform utilizes user attributes to make smart group membership suggestions, and much more. You can also explore what JumpCloud has to offer by scheduling a free personalized demo.