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.

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 are protocols
What they’re used for
Why B2B auth needs them
SSO protocols
SAML vs OIDC

What are protocols?

Protocols are communication standards for data transfer between entities. In order for two different software components to communicate, they must be able to create, send, and receive messages between each other. Protocols provide that coordination by defining the rules and formats of the exchange.

We can think of these standards of communication as a set of rules that govern interactions and formats. In essence, protocols provide consistency and interoperability: they are what allow different software systems to exchange and make use of information. Once adopted, they become cornerstones of our applications, devices, and the internet at large. As a result, when writing software, most developers consider following protocols as a best practice (you’ve probably heard of a few of these cornerstones like HTTP, SMTP, TCP/IP, SSH, TLS, DNS).

So how do protocols get made and adopted? Generally, protocols are written documents created by organizations and panels of experts who convene for the express purpose of building consensus on a particular area of software development. It usually takes many years and revisions to create a standard that sticks.

For single sign on, the protocols we will need to cover are Security Assertion Markup Language (SAML) and OpenID Connect (OIDC).

How are protocols used?

At their core, protocols are valuable because they reduce complexity for developers to transfer data. While standardizing communication between two software components may seem relatively straightforward, the complexity of that task goes up exponentially when you’re trying to do it across multiple apps and services, let alone across all apps and services in a given area of software.

Building and designing software involve a staggering amount of choices. Under the hood of any given piece of software – be it a web app, a mobile app, a microservice, a web browser, an API, or really anything capable of receiving and interpreting data – there could be any number of tools and infrastructure that go into the mix: programming languages, frameworks, libraries, cloud deployments, etc. As a consequence, the chances of two applications being similar in their form, function, or behavior are extremely low.

This is where protocols really shine: they create standards that allow different softwares to communicate independent of the individual complexities of their inner workings.

You can almost think of protocols as official languages in the UN: while you could hire an individual translator to go between each and every represented language, it’s a lot simpler, more efficient, and effective to just have two official languages for communications. With everyone using the same communication protocols (“speaking the same language”), transactions and interactions can happen much more effectively and quickly.

Why B2B auth needs protocols

B2B auth is made up of multiple organizations (lesson two) and their auth components (lesson three). They are all interconnected yet independent parts. So by nature, B2B auth is a federated system of identity, technologies, and companies.

The auth exchange between servers, applications, browsers, service providers (SPs), and identity providers (IdPs), require interoperability to make SSO work. Every B2B app will need to use a protocol capable of transferring and verifying identities across different servers.

Security Assertion Markup Language (SAML) vs. OpenID Connect (OIDC)

Both the SAML and OIDC protocols were created to enable SSO: to let a member use one single identity to access multiple systems by way of federated authentication. An IdP and SP can choose to implement either or both of these protocols as the basis for authentication. However, the protocols use very different mechanisms to achieve the same goal.

Like any choice in software, there are a considerable number of tradeoffs for B2B companies to consider. It’s useful to see the high level differentiators between the two industry standard SSO protocols side-by-side.

1. Basic definitions

SAML – a protocol for exchanging authentication and authorization data messages known as security assertions. These security assertions are standardized data statements, usually user profile information, that determine access control decisions for the end user.

OIDC – is an identity layer built on top of an authorization protocol called Open Authorization (OAuth) protocol to enable authentication. Because of their symbiotic relationship, the two protocols are often used interchangeably by developers; but to be precise, OAuth is for authorization and OIDC is for authentication. They utilize tokens to transport information about an end user and their scopes, or claims to user profile data, which determine their access. (Check out our blog on authentication vs. authorization for a more general intro to these two security processes).

2. History

SAML – Created by the OASIS organization, SAML 1.0 was released in 2002 and then upgraded to SAML 2.0 in 2005. The protocol is no longer being developed. In terms of technology, SAML is quite old and often associated with “legacy” systems.

OIDC – The OIDC 1.0 spec was drafted in 2014 by the OpenID Foundation. It’s technically the third generation of OpenID protocols. To meet new requirements and surface area, OIDC was designed on REST principles for modern API support and created to be much more developer-friendly.

3. Adoption

SAML – The SAML protocol is the most widely adopted enterprise solution for federated identity. It is commonly used by corporations, banks, healthcare, universities, and governments. After 20 years of use, it is a very mature standard that supports many industries.

OIDC – Widely adopted by B2C applications, OIDC is also gaining fast traction among large enterprises such as Google, Microsoft, Paypal, Amazon, etc. It is usually the preferred auth protocol for tech teams who are building new applications today.

4. Language

SAML – SAML is an XML-based protocol.

OIDC – OIDC is a JSON-based protocol.

5. Data format

SAML – The protocol can be quite verbose, mostly due to the XML itself which has a “envelope” like structure. The security assertions are extensible and can include custom defined attributes. That flexibility has the benefit of being able to store lots of information about an end user, but the downside of quickly making the data grow in complexity and size. Consequently, debugging a lengthy SAML assertion can be quite cumbersome.

OIDC – OIDC uses tokens like JWTs to deliver data instead of assertions. These bearer tokens, a term we’ll cover in our next lesson on OIDC, are much more lightweight in comparison to SAML security assertions. OIDC uses the singular concept of “scope” to represent app-specific permissions of an end user. It is a much more concise and standardized view of an identity.

6. Security

SAML – Due to its maturity, SAML is used by industries that are highly regulated, like banks and healthcare, that need tight security. It is a much more battle-tested protocol compared to OIDC. But, because of SAML’s complexity and bulkiness, it is also prone to development errors and gotchas which can lead to major security breaches. For example, encrypting and signing a SAML assertion is not a simple task.

OIDC – Due to its modernity, OIDC is designed with more current software practices. It’s much easier to encrypt and sign JSON and tokens with JWTs. OIDC is still maturing and, in comparison to SAML, it is yet to break into highly regulated industries and security enterprises.

7. Authorization

SAML – SAML security assertions can simultaneously provide both authentication and authorization data about an end user.

OIDC – Because it’s built on top of OAuth, OIDC also supports authorization within its protocol flow. An added bonus, OIDC can natively request user consent flows (i.e. asking the end user to grant permission).

8. Integration and app support

SAML – Built for a different era, SAML and other XML-based protocols have no clean solution for mobile or single page applications. It was made for browser based applications with web servers that could transmit and receive security assertions via HTTP redirects and HTTP POSTs.

OIDC – Designed to support APIs, OIDC is much more suited to integrate with mobile and single page applications. It is a much more versatile protocol due to its REST principles and token structure.

Should you use SAML or OIDC?

For a B2B company, the answer is both. OIDC is great for capturing future-forward, newer companies, and will likely continue to grow in popularity as the software industry shifts more decisively to an API-driven economy. But, for any company hoping to capture upmarket or enterprise clients, you need to offer SAML because of its wide adoption. Unless you’re comfortable missing out on either side of that TAM divide, you should support both protocols.

B2B customers each bring a huge swath of industry needs and legacy software requirements. Large enterprises will want to stick with SAML, but companies who are building the next widely adopted application want OIDC and are not looking back. So why stick with one protocol?

To prepare you, we’re going to deep dive into both protocols over the next two lessons. Up next is OAuth and OpenID Connect.

See you then.