The differences between OpenID Connect (OIDC), OAuth 2.0 & SAML

This article is an update to the popular Difference between SAML and OAuth blog post we published in 2017. This blog expands to cover OpenID Connect (OIDC) vs OAuth 2.0 vs SAML 2.0 (Security Assertion Markup Language).

We have seen a significant amount of development on OAuth and OpenID Connect specifications recently. So, we thought that now is a good time to update, answering your questions and to catch up with those latest developments.

You can also download a free comprehensive white paper on SAML vs OAuth 2 vs OIDC using the form below:

Identity Management Terminology

Protocols

The protocols being compared in this article are listed in the table below.

 

Actors and Roles

For the sake of simplicity I’m using a common terminology for various actors and roles.

 

Comparison of Protocol Flows

Authorization Code flow and SAML HTTP POST binding are the two most common flows for the respective protocols.

From the figures below it is possible to see that step 3 of the Authorization Code flow has an extra backend request, the Token Request.

Implicit flow removes the Token Request step and is thus practically the same as SAML HTTP POST binding. However, because of improvements in browser technologies such as CORS, implicit flow is not necessary anymore and there is strong opinion to deprecate it because of security and other reasons – see OAuth 2.0 Security Best Current Practice

SAML Artifact flow is a little less known variant of SAML and is presented here since it is very much like the Authorization Code flow.

Outline of flow steps:

1. End User navigates to protected resource of Web Application. Web Application generates an Authentication Request and redirects browser to Identity Provider
2. Identity Provider processes Authentication Request, then identifies User and asks authorization from user before submitting response back to web application.
3. With Code and Artifact flows the Web Application receives a reference handle that it must exchange for a Token.With Implicit and HTTP POST flows the application receives a Token directly. Because the Token is sent via the Web Browser there are often technical limitations to Token size.
4. In the final step the Web Application initiates an authenticated session with End User based on claims the Token represents.

 

OAuth Flow OIDC Flow

The Code flow allows specifying a PKCE Challenge with the authentication request (step 2). If the challenge is present, then a PKCE Verifier must be specified with the Token Request (step 3). PKCE protects against authorization code interception attack.

 

SAML HTTP POST binding

 

Implicit Flow

 

SAML Artifact binding

 

Conclusions

The flows look very much the same. Obviously, there are significant differences in message and request formats: SAML is based on XML, where OAuth is based on HTTP request parameters and JSON messages.

Many people will consider SAML, being based on XML, more difficult than OAuth. However, when using ready integration tools and libraries this difference often becomes irrelevant.

Basically, this means that the same kind of flows do exist for both protocols, however there is a difference in what is included in the mandatory implementation profiles.

Authorization Code flow with PKCE is the most secure and generic of these flows. PKCE implements a security feature that is not available with SAML or Implicit Flow. Because all OAuth and OIDC compliant Identity Providers are required to implement this Authorization Code flow and because message size is practically unlimited, it is the best general-purpose alternative.

 

Authorization vs Authentication

One of the most common claims is that OIDC and SAML are about authentication where OAuth is about authorization. This is, however, not always entirely accurate and needs clarification.

Authorization

In this context, authorization is a function of the Identity Provider. This function is not based on a protocol. Instead, as can be seen from figures in the previous chapter, authorization happens in the same way: the Identity Provider will first identify the user, then ask the user to authorize what the Identity Provider shares with the Application.

The Identity Provider can ask for authorization to control what identity information and content is shared with the Application. For example, the IDP can ask if the user wants to share his email address with the Application.

An Identity Provider can also ask for authorization to control the scope of an Access Token that is handed to an Application for API protection use cases. For example, the IDP can ask if the user wants to allow an Application access to some other service on their behalf. Access Token scope only exists for OAuth / OIDC.

Authentication

An application that wants to authenticate a user needs to receive identity information, i.e. claims identifying the user. Originally, claims were only defined for OIDC and SAML. However, with the introduction of the OAuth introspection service, an application can use OAuth only to receive identity claims implementing authentication use cases.

Conclusion

 

Comparison of Tokens

The underlying format for most tokens is either SAML Assertion or JSON Web Token (JWT). Both token formats are used to represent claims to be transferred between two parties.

The table below lists tokens present in OAuth / OIDC and SAML protocols.

JWT is a generic token format where claims are represented as JSON. JWT integrity is implemented by JSON Web Signature (JWS). The JWT specification by itself does not define any specific use cases. The JWT token format is, however, widely used. OpenID Connect specifies the ID Token as JWT – many vendors have selected JWT as a format for Access Token and there exist numerous API protection use cases, un-related to OAuth / OIDC, where JWT formatted tokens are used.

The format for Access Tokens is surprisingly not defined by the OAuth specification. Instead, an interoperable application is expected to treat Access Tokens as opaque strings and use the OAuth Introspection service for validating tokens. Because representing Access Tokens as JWT is quite popular, there is, however, work going on to define an interoperability profile for JWT formatted Access Tokens.

SAML Assertion is based on XML. SAML Assertion integrity is implemented by XML Digital Signature. A SAML Identity Provider uses SAML Assertion token to transfer claims to an Application. The Web Services Security profile defines how to implement protection of SOAP APIs with SAML Assertion tokens.

Conclusions

 

Mobile Applications

The Native Apps specification for OAuth allows implementing interoperability for Mobile Applications and Identity Providers.

Step 2 is where the mobile application magic happens. This step allows the mobile application to receive the authorization code from the identity provider in an interoperable manner.

There are two ways the mobile application can receive the authorization code:

1. By launching a simple http server listening on a loopback address
2. By registering a private-use Uri scheme

Step 4 is an API protection use case. The Application sends an Access Token to the API Backend. The backend invokes Introspection to validate the Access Token.

For SAML there is no interoperability profile to support mobile applications. It could be possible to use SAML for the same use cases, but this often requires special purpose support from the Identity Provider.

Conclusion

 

Devices and other “browser-less” use cases

The Device Authorization Grant and Client Initiated Backchannel Authentication (CIBA) extensions to OAuth and OIDC enable use cases without a user agent. Example use cases are authorization of devices such as smart TVs, authorization with command line tools, vending machine transaction authorization, authorization of phone calls by call centers etc.

Conclusion

 

Final Conclusions

For Single Sign-On (SSO) use cases with traditional Web Applications, it doesn’t make much difference which protocol is used. Both OAuth / OIDC and SAML will provide the most common functionality in a safe and secure way.

If you are looking for standards-based support for other use cases such as Mobile Applications or protection of REST APIs, then OAuth or OIDC is probably a better choice.

Comparing OAuth and OIDC or defining strict boundaries between the two is probably not worth it. A real-world application will be using features from both OAuth and OIDC.

Otherwise the differences are mostly subjective.

If you already know SAML and you have tools and libraries supporting SAML, then it is a good choice to continue with.

If you, on the other hand, are only at the learning stage and do not want to invest in learning XML, or you need to work with Mobile Applications or REST APIs, then OAuth / OIDC is the best choice for you.

 

Next steps

Experiment with SSO, Authorization & connecting Identity Providers with a free IDaaS Trial.

Download the full, comprehensive white paper on SAML vs OAuth 2 vs OIDC: