OIDC vs SAML: Key Differences and Which to Use

If you’re in the process of adding authentication to your SaaS app, chances are you’ve come across OIDC (OpenID Connect) and SAML (Security Assertion Markup Language) – two popular authentication protocols. But, you might not know which one is right for you.

While they’re both used for Single Sign-On (SSO), each handles the authentication process a little differently – they use different authentication flows and data formats and can have different use cases.

In this article, we’ll discuss the differences between OIDC and SAML, walk you through how each protocol works, its pros and cons, and what it’s used for to help you decide which protocol is right for you.

OIDC vs SAML: Which is right for you?

OpenID Connect (OIDC) is an authentication protocol built on top of OAuth 2.0. It allows users to log in to multiple apps using their existing identity from an OpenID provider like Google, Microsoft, or GitHub. It’s quick to set up and commonly used in modern web and mobile apps.

SAML (Security Assertion Markup Language) is an XML-based SSO protocol that standardizes how an Identity Provider (IdP) and a Service Provider (SP) exchange authentication and authorization data. It’s used in legacy enterprise environments to enable web SSO.

Use SAML if: legacy enterprise login is a priority and only if your customers absolutely require it because it’s really hard to secure and opens up too many security issues.

Use OIDC to: add enterprise SSO to your app in a dramatically easier way, most IdPs support it. It’s also an obvious choice if you’re already using OAuth 2.0 to access users' data (for example, to access a user’s Google files or Facebook profile data). The two protocols already share some features and are the best choice if you want to add social logins via providers like Google or Github.

In most cases, it’s worth supporting both OIDC (for enterprise SSO and social logins) and SAML (for legacy enterprise SSO) to cater to a broader customer base.

Read More:

• What is SAML?
• The Best 5 SSO Providers to power your SaaS app in 2024

What is OIDC?

Extending the OAuth 2.0 authorization framework, OIDC enables authentication across different kinds of apps ranging from single-page apps to mobile apps and APIs. It's commonly used for social logins via providers Google, Facebook, and GitHub and also supports Single Sign-On (SSO) authentication.

One of the unique features of OIDC is its use of ID tokens. These are JSON Web Tokens (JWT) that encapsulate an authenticated user’s details like their names, emails, and roles. JWTs are particularly compact and can be added to request headers, payloads, and URLs, making them perfect for both fully-fledged apps and APIs.

Here’s how OIDC typically works:

• When a user attempts to log into your app, they’re redirected to the OIDC provider.
• The user authenticates with the OpenID Connect provider.
• The OIDC provider verifies their identity and generates a token that contains their identity data.
• The identity provider sends the token back to your app.
• Your app validates this token and subsequently grants the user access if the token is valid.

Pros of OIDC

• It’s simple to implement: OIDC is very developer-friendly and uses a REST-like protocol to transmit tokens. The user data is also in JSON format which is easy to read and parse.
• It's web and mobile-friendly: OIDC is designed to work well in web and mobile applications and supports SSO in both environments.
• It enables social authentication: OIDC enables social logins through major OAuth 2.0 providers like Google, Facebook, LinkedIn, Microsoft, and Apple.
• More than just names and emails: OIDC protocol defines a handy userInfo endpoint, for requesting additional user data (such as profile pictures, nicknames, information on whether the email is verified, and addresses) beyond what’s included in the tokens.

Cons of OIDC

• Different providers, different OIDC interpretations: When you’re integrating with multiple OIDC providers, be prepared to spend some time figuring out how each of them implements OIDC.
  
  ‍For example, while one provider might return a refresh token along with the ID token, another might require a separate request to get it. And the user info included in the JWT? It varies between providers too.

What is SAML?

SAML is a standardized authentication protocol for exchanging authentication data between an identity provider (like Okta or Microsoft Entra) and a service provider (i.e. your SaaS app).  It’s commonly used within enterprises to enable SSO and identity federation.

SAML uses encrypted XML documents called assertions to represent user data. These assertions contain the user's details (like their name and email),  their authentication status, and their roles and permissions.

Compared to OIDC, SAML is far more complex to implement and requires in-depth knowledge of XML, XML digital signatures, and digital certificates. The learning curve is steep -  especially if you’re coming from the simplicities of REST and JSON.

However, there's a wealth of resources and how-to guides out there to help you integrate SAML into your apps easily.

A SAML authentication flow typically looks like this:

• When a user attempts to log in, your app generates a SAML authentication request and sends it to the IdP via a redirect.
• The IdP parses the SAML request and authenticates the user.
• Once authenticated, the IdP generates a SAML assertion response containing the user’s details, such as their username, attributes, and authentication status.
• The IdP sends the SAML assertion back to your app which validates the assertion, and if valid, grants the user access.

Pros of SAML

• It’s an established protocol: SAML has been around for over 20 years and is very popular at the enterprise level. It’s supported by almost all enterprise IdPs.
• It’s optimized for cross-domain SSO authentication: SAML is specifically designed to allow web-based authentication between different organization’s networks.

Cons of SAML

• It’s complex to implement: SAML uses XML, which is very verbose and difficult to parse compared to JSON.
• It’s very hard to implement securely: Most of the security vulnerabilities in SAML come from XML digital signatures which is very tricky to implement securely. One common vulnerability is the XML Signature Wrapping attack( XSW). In this scenario, an attacker modifies a signed SAML message in such a way that your app interprets the message differently than intended while the signature still validates as correct.
  
  To mitigate this risk, validate response schemas. Also, only process signed assertions as hackers might bank on the possibility that you might skip validating an assertion if no signature is found.
  
  Other security vulnerabilities to keep in mind are replay attacks and vulnerabilities introduced by XML parsers.

• Limited to web apps: SAML was primarily designed for web apps and does not integrate easily with other types of software, like APIs or mobile apps.

What can SAML and OIDC be used for?

SAML and OIDC can be used for:

• User authentication via an identity provider.
• Single Sign-On to allow users to log in to multiple apps from a single place.
• Role-based access control to restrict access only to users with the right roles or permissions. SAML assertions and OIDC ID tokens can include authorization claims that convey information about the user such as roles or group memberships.

OIDC vs SAML: When should you use each protocol?

Unless your customers explicitly ask you to support SAML, use OIDC as SAML is complex and really hard to implement securely. Besides, most enterprise IdPs (like Microsoft Entra and Okta) now support OIDC.

If you’re building APIs, mobile or native apps, OIDC is easier to implement and provides a better developer experience compared to SAML which was initially designed for web apps only.

OIDC is also a natural choice if you already use OAuth 2.0 to authorize users in your app and want to add authentication or social logins. You can use it to authenticate users through popular OAuth providers like Google, Facebook, and LinkedIn. And they can log in to your app with accounts they use every day. If your customers are developers, for instance, they can use their GitHub account to authenticate themselves.

Ultimately, the SSO protocol you support will depend on your customers. Usually, you end up having to support both protocols to support those who use OIDC and those who’re still using SAML.

FAQs

Should I use SAML or OIDC?

Whether you use SAML or OIDC depends on your app’s needs and your customers. Here are some factors to consider before settling on a protocol:

• Are you building an API? Use OIDC. It uses JWTs to verify user identities – JWTs are lightweight, self-contained, and can be added to the header or payload of the API request.
• Are you building for enterprises? Use SAML because chances are most of your customers are using it to enable SSO.
• Are you tight on time? Implementing SAML authentication can take a long time especially if you’re not familiar with XML and XML Digital Signatures in particular. It’s much easier to get up and running with OIDC – it uses the much more popular patterns – JSON and REST.

Is SAML or OIDC more secure?

It depends on how the protocol is implemented rather than the protocol itself. SAML is a lot harder to implement and therefore more prone to implementation errors that can cause security vulnerabilities.

Can I use both SAML and OIDC?

Yes, you can use both SAML and OIDC to add authentication to your app. Whether you should depend entirely on the customers you serve – some may require you to support OIDC while others might ask for SAML.

Is SAML only for enterprise apps?

No, SAML is not only used for enterprise apps. It can also be used in general consumer apps. OIDC is however usually preferred because it’s easier to implement and supports social logins.

Next steps

Don’t want to choose between OIDC and SAML or go put in the engineering hours to implement them from scratch? Avoid the headaches by using a done-for-you authentication platform like WorkOS:

• Get started fast: With SDKs for every popular platform, support for both OIDC and SAML and support for all major corporate identity providers, you can implement SSO in minutes rather than weeks.
• Avoid the back-and-forth: WorkOS’ Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard - whether they bring 10 or 10,000 users to your app.

Explore Unified SSO by WorkOS.