OIDC vs. SAML

When trying to set up authentication for an application, you might hear people talk about “OIDC” and “SAML”. This is especially true when you have a lot of different applications that you want the end user to be able to use the same username and password for; for example, inside of a business, you might want your employees to log into an HR application, a task-tracking board, and CRM software with the same credentials. So what do these two four-letter abbreviations mean, anyway? What are the differences between them? And how do they help you authenticate your users? 

Single sign-on 

Both OIDC and SAML serve the same purpose: allowing for single sign-on, or SSO. SSO means that a user only has to provide credentials one time in order to log into different independent software systems. What’s more, users can switch between applications without having to sign in again. This is accomplished by creating a web application called an identity provider that handles authenticating the user. This has the additional benefit of removing the burden of having to securely store and verify user login information such as passwords inside of the application; you can focus on your business logic instead. 

This introduces a problem, though: how do your applications and the identity provider communicate with each other? Your app needs some way of telling the identity provider that someone needs to authenticate. And after the authentication process is done, the identity provider needs to tell your app information about the user so that your app can know who logged in. There also needs to be some way for your app to trust that this information comes from the identity provider and hasn’t been tampered with. 

This is where authentication protocols such as OIDC and SAML come in. They specify exactly how your app and the identity provider communicate with each other. They also lay out rules for identity tokens, which are sent from the identity provider to your application when the user has completed the authorization flow. They contain bits of information about the user so that your app can identify them, and they’re also cryptographically signed, allowing your app to trust that information. 

So why are there two of them? 

SAML has been around for a while. Originally published in 2002, it was created at a time when XML was very popular and the internet was very different from what it is today. XML was very popular at that time, so the identity token that SAML uses is XML-based. And since web browsers were still new on the scene and modern frontend frameworks like React and Angular hadn’t been invented yet, it was a given that any web application, no matter how small, would have a backend, which SAML apps could utilize to verify the token that they got back from the identity provider. 

Over time, though, some pain points started to emerge. The web started to move away from XML, viewing it as clunky and error-prone. XML is a very hierarchical markup language, and using it for a particular use case requires the user to become familiar with a complex set of rules governing the relationship between the various XML elements. Moreover, these rules are completely different depending on what you’re using XML for. Learning how the XML specification works in SAML won’t teach you much about how NOAA uses XML to convey weather information, for example. 

 At the same time, Javascript became a much more popular programming language as computers became more powerful and web browsers became more sophisticated, allowing for web apps to be executed entirely inside of the end user’s web browser. A data format called JSON, short for Javascript Object Notation, began to be widely used. JSON isn’t a markup language at all but rather a data format which is very easy to pick up for anyone familiar with Javascript. As a result of its ease of use, developers began replacing XML with JSON in more and more places. 

OIDC, an abbreviation for OpenID Connect was published in 2014 as a response to some of these issues. It uses JWTs (JSON Web Tokens) as its identity tokens. Since JWTs are based on JSON, they have a smaller footprint and are easier for applications to parse. It contains a secure way for a single-page web application to use the protocol without the need to create a backend. And it’s built on top of a modern authorization protocol called OAuth; OAuth and OIDC can be used hand-in-hand to secure REST APIs, a process that can be cumbersome using SAML. 

In summary, here are some of the differences between the two protocols: 

So which should I use? 

For creating new applications that you plan to integrate with modern identity providers, OIDC should be your first choice. It’s a modern, flexible protocol that can be used with a wide range of web and mobile applications. Identity providers release software packages for a variety of platforms that take much of the guesswork out of integrating your application with an identity provider; for example, MSAL allows you to use Azure AAD and Azure B2C as your identity provider, and it’s available for many different languages and frameworks. 

However, SAML is still in wide use throughout the internet. A lot of SaaS applications only support SAML, so if you want to use one of them, you’ll still need to use the protocol. The SAML protocol also supports some scenarios out-of-the-box that OIDC doesn’t, like requiring a signed token from the service provider. Luckily, modern identity providers allow for single sign-on between SAML and OIDC applications, so you can combine the modern flexibility of OIDC with the legacy support of SAML.