OIDC vs SAML

OpenID Connect (OIDC) and Security Assertion Markup Language (SAML) are both authentication protocols that allow identity providers (IdP) to implement user validation and access control. Each defines its own mechanism to maintain virtual identities of verified users, which are then used to grant or reject access to protected applications.

An IdP maintains a database of user identity information. A service provider (SP) relies on this information to authenticate a user, sometimes only once for multiple applications (single sign-on). Both OIDC and SAML are standards that define just how this information is to flow between these two parties. The end goal for both is the same: user authentication. But the underlying methodology to achieve the goal is different.

Authentication is a process by which the identity of a user, or a process, can be validated. This is usually done to restrict access to protected applications and/or resources.

SAML 2.0, which is the current version of the standard, has been around since 2005. It uses XML to format identity information. XML is an established information-formatting standard which encodes documents, such that they are easily understandable by both humans and computers. For transferring or receiving XML-encoded information, it uses basic SOAP or HTTP requests. The service requesting identity information is defined by the SAML contract, as a service provider (SP). Here’s what a typical SAML authentication flow looks like:

1. Before the SP can talk to the IdP for identity verification, the two parties must first get to know each other better. They do so by exchanging preliminary information, via metadata, which includes details like:

   • Public keys (used for encryption)

   • Supported encryption algorithms

   • Endpoint URLs (where to send SAML messages)

   • Supported connection methods, and

   • Supported XML attribute formats

Once both the SP and the IdP know these specifics about each other, they reconfigure themselves accordingly.

2. As a user tries to log in, the SP sends an authentication request to the IdP. This request is known as SAML AuthnRequest.

3. The IdP checks the user identity, creates an encoded SAML response, known as a SAML assertion, and sends it back to the SP.

4. The SP parses the SAML assertion XML and, based on the response, either grants or rejects user access to the application.

A relatively newer, but well-maintained protocol, OIDC is built on top of the OAuth 2.0 framework. OIDC uses JSON-based web tokens (JWT) to structure data. JWT is an industry standard which defines the rules to represent and securely transfer claims between two parties. Think of claims as encrypted, sensitive user data, used to support identity management and verification. For transportation, OIDC uses default HTTPS flows.

OIDC scopes define the claims (the user attributes) that an application can have access to. The IdP maintains a list of acceptable scopes, and an application can choose which to request, depending on its needs. After a user explicitly consents to sharing their details (which includes the scopes), the IdP makes the scopes available to the application.

To better understand how scopes work in a typical OIDC flow, let’s consider a web application that authenticates a user based on their username and password. Post-authentication, it also sends them a sequence of welcome emails.

(Note: OIDC supports a number of different authentication flows. Below is an example of the simplest OIDC flow, known as the implicit flow.)

1. Just like in SAML, the Relying Party (RP) and the IdP must exchange metadata before they can start communicating. For OIDC, however, the minimum metadata exchange requirements are relatively simpler. Both parties must agree on possible scopes, the IdP must assign a secret and client-ID to the RP, and the RP must share the endpoint it wants to receive codes and/or tokens on.

2. When a user logs in to the application, the application redirects them to the IdP. It includes the client-ID, along with the requested scopes, which in our case, will be the user’s email address.

3. The IdP, in turn, redirects the user to the login screen.

4. Once the user’s identity has been successfully verified, they are prompted to grant the application access to their data (specified by the requested scopes).

5. If the user grants the access, the scope values are made available to the application via the preconfigured endpoint.

6. The application can now use the user's email address to send them the welcome sequence.

• Since SAML is an older standard, it is very hard to use it for authenticating modern application types like single-page applications (SPAs) and smartphone applications. It simply wasn’t built for them. Conversely, OIDC is ideal for such apps.

• OIDC uses JWTs, which are smaller in size, and require lightweight processing. On the other hand, the XML documents used by SAML are much larger, and relatively difficult to process.

• OIDC supports user consent by default. The same can be achieved with SAML, but requires extensive manual development.

• Since SAML has been around for much longer, it’s still trusted by a lot of organizations, including government entities. It’s certainly more feature-rich, but OIDC is now starting to catch up.

• OIDC is much easier to set up, especially in a consumer-centric environment, where the basic identity features are required.

OIDC was designed to be the modern replacement of SAML, as it replicated most of the fundamental SAML use-cases, while reducing the processing overhead caused by XML and SOAP based messages. Most security flaws don’t stem from intrinsic problems in any of the two standards, but instead, are caused by implementation mistakes. However, it can be argued that since SAML is a lot harder to implement than OIDC, it’s also more prone to implementation errors. Moreover, there are a lot of security threats and vulnerabilities associated with XML that must be avoided during SAML implementation, adding to the complexity.

Conversely, since OIDC is based on OAuth 2.0, it incorporates a lot of the documented threat model and security considerations. Encrypting JSON is also a lot easier than XML, which again, reduces the chances of implementation errors.

Via scopes, OIDC gives users the ability to choose the level of information they want to share with an application. E.g. an application only asks the user to share their email address, as opposed to sharing their entire profile. This establishes a win-win contract between the user and the application; the application gets what it needs to improve a user’s experience, and the user gets to only share bare-minimum personal information. Yes, this feature can be added to SAML-based systems as well, but it would require additional development, because SAML doesn’t support it, out-of-the-box.

Both OIDC and SAML can be used to implement single sign-on (SSO), which reduces the need to log in multiple times, and hence, decreases the probability of phishing attacks. However, just because the probability is low, doesn’t mean that they can’t happen. The Cofense Phishing Defense Center discovered a phishing tactic which manipulated OIDC to reveal user data, without a password, despite multi-factor authentication. Similar phishing attacks have also been carried out on SAML implementations in the past. Once again, it’s difficult to answer whether one prevents phishing better than the other; a lot of it is dependent on the security considerations made during the implementation.

Both SAML and OIDC can be used to implement single sign-on, which means that the user only has to remember one password to log in to the identity and access management (IAM) service. That single login can also be protected by requiring users to provide an additional authentication factor. Once users are securely logged into the IAM service, they can seamlessly access all protected applications, without having to enter any more passwords. This is big in preventing brute-force attacks, in which attackers repeatedly enter potential passwords, in the hope of eventually getting a match. No passwords = no chance of brute force attacks!

OIDC and SAML are both powerful authentication technologies with unique features. Which one you choose for your organization, depends on your specific needs. If you:

• Want to quickly set up an identity platform, choose OIDC over SAML, without thinking twice. Implementing a basic OIDC solution is much simpler, compared to SAML, which would require heavy-weight XML processing.

• Have an API-centered architecture, with a lot of mobile and single-page applications, use OIDC. It will guarantee a much more efficient and interoperable experience.

• Want to implement a mature standard, something that has been around for a long time, then choose SAML. It’s feature-rich, gets the job done, and has been a staple of enterprise networks for over a decade.