OAuth vs. SAML vs. OpenID Connect

Today there are three dominant open web standards for identity online: OAuth, SAML and OpenID Connect. In the following article we’ll examine how the technologies relate to each other, and under which circumstances each should be used.

OAuth 2.0 vs.  OpenID Connect

The first thing to understand is that OAuth 2.0 is an authorization framework, not an authentication protocol. OAuth 2.0 can be used for a lot of cool tasks, one of which is person authentication. OpenID Connect is a “profile” of OAuth 2.0 specifically designed for attribute release and authentication. From a technical perspective, the big difference between OpenID Connect and OAuth 2.0 is the id_token–there is no id_token defined in OAuth 2.0 because it is specific to federated authentication. The id_token provides an additional layer of security to user sign in transactions by adding:

• A nonce, which is sent by the client and enables the integrity of the response to be validated;
• A hash of the access token;
• A hash of the code (optional).

Net-net, OpenID Connect is laser-focused on user authentication, whereas OAuth 2.0 was left generic so it could be applied to many authorization requirements, like API access management, posting on someone’s wall, and using IOT services.

SAML vs. OpenID Connect

At the risk of over-simplification, OpenID Connect is a rewrite of SAML using OAuth 2.0. Let’s look at a few similarities and differences

IDP / SP vs. OP / RP

In SAML, the user is redirected from the Service Provider (SP) to the Identity Provider (IDP) for sign in. In OpenID Connect, the user is redirected from the Relying Party (RP) to the OpenID Provider (OP) for sign in. The SAML SP is always a website. The OpenID Connect RP is either a web or mobile application, and is frequently called the “client” because it extends an OAuth 2.0 client. In both cases, the IDP/OP controls the login to avoid exposing secrets (like passwords) to the website or app.

Assertion vs. id_token

In SAML, there is an “assertion”–a signed XML document with the subject information (who authenticated), attributes (info about the person), the issuer (who issued the assertion), and other information about the authentication event. The equivalent in OpenID Connect is the id_token. This is a signed JSON document that contains the subject, issuer, and authentication information.

Front Channel vs. Back Channel

A big difference between OpenID Connect and SAML is the use of “front-channel” and “back-channel”:

• The front-channel is the browser;
• The back-channel is communication directly between the application and the IDP/OP.

Although SAML defines back-channel mechanisms, they are rarely used in practice. The most common way SAML sends the request XML and response XML (assertion) is via the browser. Most SAML sites use the “POST Binding” to send the response. In this scenario, the browser is sent an HTML form from the IDP with the response XML as a form parameter. There is some JavaScript in the form to auto-submit the data back to the SP. It’s a neat trick because the SP and IDP don’t need network connectivity to communicate–the browser acts as a middle-man! OpenID Connect defines a similar mechanism (“Form Post Response Mode”)–but unlike SAML, it’s use is more the exception than the rule. Both OpenID Connect and SAML frequently use something like the “Redirect Binding” to send the request. This is where the URL parameters are used to send the XML. This also leverages the browser. OpenID Connect normally uses the back channel–a direct call from the RP to the OP–to retrieve this information. The attributes (or “user claims” in OpenID jargon) are available to the client by calling the user_info endpoint, which is a JSON REST API. However, because this is OAuth 2.0, the client needs a token to call this API. And according to the OAuth 2.0 framework, the token is obtained from the OPs token endpoint using the back channel.

Which protocol, when?

So when should SAML be used, and when should OAuth 2.0 or OpenID Connect be used instead?

• Mobile applications: no question–use OpenID Connect.
• If the application already supports SAML: use SAML.
• If you are writing a new application, use OpenID Connect–skate to where the puck is going!
• If you need to protect API’s, or you need to create an API Gateway… that’s a topic for another blog. Short answer: use OAuth 2.0 or the User Managed Access (“UMA”) protocol.

The good news is: if you’re using the Gluu Server, you already support single sign-on (SSO) for SAML, OpenID Connect and OAuth 2.0 applications.

About Gluu

Since 2009, organizations around the world have trusted Gluu for large-scale, high-security identity & access management (IAM). Gluu’s comprehensive open source platform provides industry-leading solutions for web and mobile single sign-on (SSO), two-factor authentication (2FA), and API access management. Built on open web standards like OpenID Connect, OAuth 2.0, WebAuthn (FIDO), and UMA, customers choose Gluu for performant, compliant and modern authentication, authorization, federation and hybrid cloud identity. Ready to discuss your next enterprise IAM project? Contact us.