OpenID Connect vs. SAML

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.

SAML is the way to go if legacy enterprise login is a priority and your customers absolutely require it. Otherwise, you are better off with OIDC. SAML is really hard to secure and opens up too many security issues.

With OIDC you can add enterprise SSO to your app in a dramatically easier way, and 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.

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:

1. When a user attempts to log into your app, they’re redirected to the OIDC provider.
2. The user authenticates with the OpenID Connect provider.
3. The OIDC provider verifies their identity and generates a token that contains their identity data.
4. The identity provider sends the token back to your app.
5. 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:

1. When a user attempts to log in, your app generates a SAML authentication request and sends it to the IdP via a redirect.
2. The IdP parses the SAML request and authenticates the user.
3. Once authenticated, the IdP generates a SAML assertion response containing the user’s details, such as their username, attributes, and authentication status.
4. 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.

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.