OIDC vs SAML: The Differences

OpenID Connect (OIDC) and Security Assertion Markup Language (SAML) are popular identity and authentication protocols today. But which one is better for your use case? What are the differentiators? This detailed comparison resource will shed some light on the technicalities and help you make an educated decision for your SaaS offering. Without further ado, let’s get started.

What Is OIDC (OpenID Connect)?

OpenID Connect (OIDC) 1.0 is essentially an identity layer added to the OAuth 2.0 protocol. It is a newer protocol than SAML (more on this in the next section). OIDC allows clients to verify end-user identity according to the authentication carried out by an authorization server. It also lets clients obtain fundamental profile information about end-users in a REST-like and interoperable manner.

OIDC lets all types of clients, including mobile, JavaScript (JS), and web-based clients, request and receive information about end-users and authenticated sessions. It offers an extensible specification suite, which allows participants to utilize optional functionality, such as discovery of OpenID Providers, session management, and encryption of identity data, as needed.

What Is Security Assertion Markup Language (SAML)?

Security Assertion Markup Language is an open standard that allows clients to share security information about identity, authentication, and permission across different systems. SAML is implemented with the Extensible Markup Language (XML) standard for sharing data. It offers a framework for implementing Single Sign-On (SSO) and other federated identity systems.

SAML is managed by the Organization for the Advancement of Structured Information Standards (OASIS). It’s an important component that enables users to access multiple apps, services or websites via a single login process. Identity and authentication levels are shared across different systems and services using the SAML protocol to request, receive, and format identification data.

SAML and OIDC: The Similarities

Both OIDC and SAML are trusted identity protocols. They allow users to be authenticated, transferring user information safely from the system responsible for the authentication, the Identity Provider (IdP), to the app or service the end-user is attempting to access.  A key way to allow for this form of Single Sign-On (SSO) is to establish trust between the application and the IdP.  

SAML and OIDC are core protocols utilized in all kinds of SSO solutions, regardless of the nature of the app or website. SSO solutions create a system where users are only required to authenticate once with the IdP. Following the authentication, they should be able to access any one of the apps configured to trust the IdP.  Read more in our comprehensive SSO guide.

The fundamental login flow for OIDC and SAML is as follows: 

1. The user logs in via the Identity Provider
2. They choose the application they wish to visit
3. The user’s information is transferred from the IdP to the browser of the user
4. The user’s information is subsequently passed to the application
5. The app establishes if they are authorized to access the resources
6. The user is provided access to the app

If the user directly accesses the application before logging into the Identity Provider (IdP), the login flow will be a little different. It will look as follows:

1. A user makes an attempt to log straight into the app
2. The app redirects the login attempt via the user’s browser to the IdP
3. The user logs in to the IdP (or is told they are already logged in)
4. IdP establishes that the user can access the app that released the request
5. The user’s information is transferred from the IdP to the user’s browser
6. The user’s information is then passed on to the app
7. The app establishes that they are authorized to access the resources
8. The user can access the app

Related: Authentication Standoff: OAuth vs SAML

OIDC vs SAML: The Differences

Both protocols attain the same end goal. However, the methodology used to authenticate users in terms of technology, capacity and method changes.

• IdP/SP vs OP/RP— With both, the app redirects the user to the identity provider for authentication. This is known as a Service Provider (SP) in SAML and a Relying Party (RP) in OpenID. The contrasting element here is that SAML doesn’t connect smoothly with certain apps, especially mobile ones. OpenID works well with both mobile and web-based apps.

• Mobile-Centric Authentication – OIDC utilizes RESTful communication to develop lightweight JSON security tokens, which are transferred between the IdP and the relying party. This means OpenID Connect is a leading protocol for mobile-centered application authentication. SAML was primarily created for the authentication of web applications. 
  
  Because Security Assertion Markup Language uses XML, there is no potential for this to be utilized in mobile applications, providing OIDC with an advantage to be employed solely in mobile applications.

Verdict: SAML is good for the web, while OIDC is much more versatile.

• Message Format— With OpenID Connect (OIDC), there is a JSON Web Token (JWT) known as id-token, which gives authentication information. In SAML, there are assertions that represent the attribute, authorization, and authentication statements, all formatted via XML. JWTs are light in comparison to heavy-weight XML assertions.

• Support for API — OIDC came into existence because SAML is heavy and can’t integrate effectively with APIs. OIDC uses RESTful API communication which uses the HTTP communication channel to dispatch light JSON security tokens used in the process of authentication. SAML uses SOAP, a protocol layer on HTTP, but instead dispatches heavy XML messages.

Verdict: OIDC is lighter and more performance-friendly than SAML.

• Static Authentication – With Security Assertion Markup Language, static authentication is needed when the IdP and the relying party have to be configured to identify one another before the transfer of data occurs. This can create all kinds of performance issues. However, this is not the case with OIDC, which is by far the faster and more resource-friendly protocol.

• Implementation – OIDC is developer-friendly and simpler to implement, which broadens the use cases for which it might be implemented. It can be implemented from scratch pretty fast, via freely available libraries in all common programming languages. SAML can be complex to install and maintain, which only enterprise-size companies can handle well.

Verdict: OIDC wins the user-friendliness battle as well.

• User Consent – OpenID Connect is essentially a layer put on an OAuth framework. Therefore, it can offer a built-in layer of permission that asks a user to agree to what the service provider might access. Although SAML is also capable of allowing consent flow, it achieves this by hard-coding carried out by a developer, not as part of its protocol.
  
• Security – When people want to prioritize secure data exchange,  Security Assertion Markup Language still has the edge. We also recommend you to check out the SAML Security Cheat Sheet by OWASP. On the security front, OIDC is still maturing. It still cannot match SAML when it comes to sensitive use cases like banking, healthcare, or government related platforms.

Verdict: SAML is still more secure than OIDC in general. 

Which One is Best For You?

Both of these authentication protocols are good at what they do. There is no clear winner. As always, a lot depends on your specific use case/s and target audience. You need to determine what your organization is attempting to achieve. 

For example, if you need authentication that is light and highly interoperable with mobile apps and APIs, you can opt to implement OIDC. It is also more Single Sign-On (SSO) friendly and lighter than SAML. On the other hand, SAML is a more established federation protocol and has been in existence for a longer period of time, probably making it the more obvious option when security is a priority. 

There is also the possibility of enjoying the inherent advantages of both together. SAML’s concept of “trust” is highly effective for accessing apps via portal, accessing resources, and for enterprise-scale SSO activity. On the other hand, you have the user-friendliness and scalability of OIDC which is great for mobile use cases. Adopting a hybrid approach is probably something you should consider.

Start For Free