Which Single Sign-On (SSO) is for you? SAML vs OAuth vs OIDC

Comprehensive overview of the most common questions about Single Sign-On (SSO). Choose the right standard for your applications.

Nowadays, SSO is omnipresent — not only in everyday life but also in organizations. Authentication can now be seamless, practically never requiring you to provide your password, which is both comfortable and secure. But we are not here to talk about the general pros and cons of SSO. The concept is not new, and everybody loves it. The reality, however, does not usually look as bright as the pretty graphics you see in every PowerPoint presentation. You might already have some identity infrastructure in place: Active Directory here, Google Workspace there, with some workarounds on top of it. It was supposed to be simple and straightforward, but it is quite the opposite — you are looking at the unreadable map of your own identity, and, in the end, you are not really sure which credentials you should use to log in to your Slack account. Not really how you imagined it. You still have to provide your password in many places, and if you are tired, you might not even notice good-looking phishing along the way.

Now you finally want to take the matter into your own hands (or just understand what is going on with SAML, OAuth, and OpenID Connect), you start googling, but the road gets bumpy. You read more and more, but you cannot find anybody who will answer your real-life questions. To fully grasp the absurdity of the problem, we will dive into an analogy.

In search of an SSO solution…

Let’s say you own a restaurant and would like to start serving your customers ice cream. You do not know the best way to store ice cream in the restaurant, so you google it and start reading from the top of the page. The first article is a comparison of freezers versus fridges. It states that you have to store ice cream in a freezer, since it melts in a fridge. Not very helpful. The second article is about the history of fridges and food storage options across centuries. But wait — the following article mentions that most fridges have a built-in freezer compartment, specifically for ice cream. So which one is better?

Two hours later, you know everything about the person who invented freezers. You can also easily explain how both a fridge and a freezer work. But you still don’t know which one is the best for you and your restaurant — do you need a separate freezer, or is the built-in compartment enough? Or maybe both? Is the temperature the same? Which one is more comfortable for the servers to use?

Identity is like ice cream — it will melt away and spill everywhere if not stored correctly.

There are a lot of articles comparing SAML versus OAuth without even mentioning OpenID Connect. Many of them are simply misleading. Even if they mention OpenID Connect, they do not tell you which one to choose after all — and you want to know which one is better and more secure. You want to decide what is best for your organization, but everyone gives you random pieces of information — like “SAML is an XML-based standard, and OAuth uses JSON”. Or you might stumble across a statement such as “SAML is mostly for enterprises” — but why?

It all may sound confusing, but you do not have to worry. If you want to implement SSO and do not know which standard to choose, this article is for you. It will answer the following questions:

• What is the difference between SAML, OAuth, and OpenID Connect?
• When to use SAML, OAuth, and OpenID Connect?
• Why use OAuth instead of SAML? Is OAuth better than SAML?
• Can SAML and OAuth work together?
• What does my Identity Provider offer, aka “is Okta SAML or OAuth”?
• What does my Service Provider offer?

What is the difference between SAML, OAuth, and OpenID Connect?

Let’s start with a quick recap of SAML, OAuth, and OIDC. We will not discuss the exact specification of each flow but rather focus on the essential information.

SAML, in the most basic (and the most popular) setup, allows you to pass information about a user between an Identity Provider and a Service Provider (Client Application) via the user’s browser (User Agent). It does not require a direct connection between the Identity Provider and the Service Provider — everything happens via browser redirects. The user requests a signed document that confirms their identity from the Identity Provider, gets authenticated, and then sends the signed document to the Service Provider in order to log in. The signed document can also include information about the user’s privileges, groups, etc.

OAuth (and we are talking only about OAuth now) is an authorization standard. It allows for access delegation, e.g., if you want another app to access your photos on Google. It should not be used for authentication by itself — and if you want to know why, you can read more on this case here.

However, OAuth may be used for authentication with some additional features (like a fridge with an add-on freezer — perfectly suitable for ice cream). OpenID Connect is the specification of these features. If someone says that they use OAuth for SSO, they usually mean OAuth authorization code flow with OpenID Connect. There are still some legacy systems using OAuth without OIDC for a pseudo-authentication flow, but this is a completely different story.

OpenID Connect is widely used not only in organizations but also in everyday scenarios like “Log in with Google” or “Log in with Facebook”. The OAuth flow is quite different from the SAML flow — the main difference is that some actions happen in the user’s browser (the front channel), and some — directly between the Client Application and the Identity Provider (the backchannel). This provides a potential attacker with very little attack surface — the most important requests are sent through the backchannel.

When to use SAML, OAuth, and OpenID Connect?

With web applications, it all boils down to whether backchannel communication is required. As I already mentioned, SAML is all frontchannel, whereas all the important actions in OpenID Connect happen in the backchannel. It means that for OIDC the Service Provider will need to send HTTP requests to the Identity Provider. In case you use an external Identity Provider (like Google, Okta, or Azure AD), it will be perfectly fine. However, if you use an internal Identity Provider (like AD FS or an internal KeyCloak), the communication will not be possible (at least without a proxy).

As you see, you can either use OIDC or SAML in three out of four above scenarios. Of course, this is possible only if your Service Provider offers both options. We will discuss this in more detail in the following sections. However, if every possibility is on the table, I would recommend choosing OIDC.

Moreover, there is also a flow called SAML Artifact Binding. It is a crossover between SAML and OAuth — the exchange of the SAML Response (the signed document) happens via the backchannel. However, it is quite rare — there are also much fewer integration possibilities for SAML Artifact Binding than OIDC. In most cases, if you cannot decide between SAML Artifact Binding and OIDC, I would suggest you choose the latter.

Why use OAuth instead of SAML? Is OAuth better than SAML?

In my opinion, SAML is much easier to learn than OAuth (and OpenID Connect). SAML is pretty straightforward: you read a few articles and can easily grasp the basic concepts. On the other hand, OAuth is hard to get into — there are multiple different flows, extensions, and lots of RFCs.

It is also worth mentioning that SAML is based on XML — which, as it turns out, is not the best if you aim for security. Most of the vulnerabilities that may happen in SAML are due to twists and turns in the XML processing, improper configuration, or some weird XML features that nobody uses. Vulnerabilities in SAML are usually a big deal, like authentication bypass or privilege escalation. Obviously, you can do SAML securely, but you and your developers have to be mindful of what can go wrong.

On the contrary, the design and architecture of OAuth are much more security-friendly. OAuth is indeed more difficult, but it is also harder to introduce vulnerabilities to your code as long as you stick with known libraries and specifications. Honestly, SAML is also easier to attack — vulnerabilities in OAuth are usually more complicated, and you have to fully understand OAuth to find something, especially anything that is high-risk.

You might wonder, at this point, whether you should switch to OpenID Connect if you use SAML. As I mentioned before, SAML is a widely used standard, and there are use cases when you cannot use OIDC. It is perfectly fine to use SAML, but you have to be aware of the possible pitfalls and take responsible precautions.

Can SAML and OAuth work together?

Many people wonder if SAML and OAuth can work together — this question has two correct answers.

If we are talking about a single integration, you may choose either SAML or OpenID Connect as a Single Sign-On. As we already discussed, they both serve the same purpose here — passing information about your identity from one entity to another. However, you might offer an option of logging in to your application with Google via OAuth OIDC or with Keycloak via SAML. These are two separate integrations with the same application.

If you look at this question from the perspective of an organization, then yes — SAML and OAuth (and OpenID Connect) can and usually do work together in big architectures. Some apps may be integrated using SAML, and some may be integrated using OIDC — depending on the use case. You don’t have to choose the same one for every integration.

An example architecture can look like this:

What does my Identity Provider offer, aka “is Okta SAML or OAuth”?

As for now, we know that we have some kind of a choice — SAML or OIDC. However, this choice is limited by which integration options your Identity Provider and your Service Provider have. Let’s look at the Identity Providers first, as this can be a lot more confusing.

Let’s say you want to manage identity in your organization using Okta. Okta would be a central place where you change users’ personal data, information about groups, and their privileges. And when you need to implement SSO in a different application, like WordPress, it will be good to know your options, so you ask yourself — is Okta SAML or OAuth?

In this case, Okta will be acting as an Identity Provider. Okta allows integration using both SAML and OIDC — most Identity Providers allow you to use both of these options.

However, you might have more than one service acting as an Identity Provider. For instance, you may use Google and want to log in to Google using your Okta account. Then you also want to use your Google account to log in to other applications (since many apps are already integrated with Google). In this case, Okta will be acting as an Identity Provider, and Google — as both an Identity Provider and a Service Provider.

What does my Service Provider offer?

As was mentioned before, this is not always the case that a Service Provider offers both SAML and OpenID Connect. Sometimes it offers only SAML, sometimes — just OIDC. However, I think the “only SAML” option is more common, as it also allows you to integrate with an internal Identity Provider. Then you do not really have a choice — you only use what is available.

I also recommend choosing built-in software features instead of any extensions. If you decide to select the latter option, it is better to audit the extension thoroughly before using it, considering possible threats and the supply chain security. You might also consider if the SSO functionality has been pentested.

You should remember to review the whole configuration of the integration with your Service Provider. If you only check whether it works, you might forget to enable essential security features and end up with a nasty case of authentication bypass.

Some Service Providers might also offer group provisioning, which means that you can manage your user’s privileges in one place (in Identity Provider’s panel). It is possible to pass information about groups both via SAML (in the AttributeStatement) and OpenID Connect (via custom claims).

Final thoughts

Vulnerabilities in SSO integrations are quite common — both if you write the integration feature internally and if you configure it incorrectly. I believe the best remediation is keeping your knowledge up to date as well as subjecting yourself to regular penetration testing. Keep in mind that the state of the authentication solutions, including SSO, is one of the most crucial aspects of any application’s security.

If you ever wonder about the state of your SSO integrations and want to discuss identity management security in your organization, feel free to contact me.