49,172 reads

Demystifying OAuth 2.0 and OpenId Connect (and SAML)

by Prashant RamApril 24th, 2018

Too Long; Didn't Read

<strong>OAuth 2.0</strong> is a set of defined process flows for <strong>“delegated authorization”.</strong>

Companies Mentioned

Coin Mentioned

featured image - Demystifying OAuth 2.0 and OpenId Connect (and SAML)

Understanding delegated authorization (OAuth 2.0) and federated identity (OpenId Connect and SAML)

OAuth 2.0 and OpenId Connect

OAuth 2.0 is a set of defined process flows for “delegated authorization”.

OpenId Connect is a set of defined process flows for “federated authentication”. OpenId Connect flows are built using the Oauth2.0 process flows as the base and then adding a few additional steps over it to allow for “federated authentication”.

Delegated Authorization

Let’s say Joe owns certain resources(eg. Joe’s contact list) that are hosted on some server (eg. google.contacts server). Now, Joe wants an application that he is using (eg. Yelp), to be able to access his resources (i.e. his contact list) that is on the google.contacts server, and import it into the Yelp App. Joe needs some mechanism by which he can “authorize”, the Yelp app to access his contacts on the google.contacts server.

Joe can do this by using the OAuth 2.0 flow and delegating the “authorization” to access the google.contacts resource, to another server (accounts.google.com). Thus, the Yelp app gets “authorized” to access Joe’s resources on the google.contacts server, only after the accounts.google.com server has granted authorization to Yelp to do so.

Thus, in effect Joe has “delegated” the responsibility of authorizing access to his resources to the accounts.google.com server (Authorization server). This is called “Delegated Authorization”.

OAuth 2.0 Terminology

In the above example Joe is considered the “Resource Owner”, since Joe owns the resource (Joe’s contact list). The server on which the resource resides(google.contacts server) is called the “Resource Server”. The Yelp App that is trying to access the resources on the resource server is called the “Client”. The server that authorizes Yelp to access the resources (accounts.google.com) is called the “Authorization server”.

Resource: Joe’s contact list
Resource Owner: Joe
Client: Yelp App
Resource Server: google.contacts server
Authorization Server: accounts.google.com server

Thus, Joe (resource owner) is “delegating” the responsibility to “authorize” access to his resources(joe’s contact list ) hosted on the “resource server” (contacts.google server), to the authorization server (accounts.google.com server).

The OAuth 2.0 Process Flows

OAuth 2.0 consists of several different process flows to achieve this “delegated authorization”. The following are the two most commonly used,

Authorization code flow (front channel + back channel), most commonly used process flow.
Implicit code flow (front channel only) , used in pure JS applications (eg. Pure Angular or pure React, Single Page Applications, that do not have a backend web server).

OAuth 2.0 Authorization Code Flow

The “OAuth 2.0 Authorization code Flow” is the most commonly used flow in OAuth 2.0 to achieve “delegated authorization”.

Joe is on the Yelp App, and clicks on a button within the Yelp App which says “Import Contacts from Google”.

Note that Joe is not attempting to sign on to Yelp using his google account. Rather Joe is simply trying to import his contact list from Google contacts into Yelp.

This distinction is important because OAuth 2.0 flow is designed to “grant authorization” and is not meant to be used to “authenticate” Joe (enabling him to sign into Yelp using his google or facebook account).

The part where we give Joe the ability to sign on to Yelp account using his google login is part of the OpenId connect flow, and not the OAuth 2.0 flow. OpenId connect is used to “Authenticate” a user. The OAuth 2.0 flow is simply meant to grant “Authorization” to the users resources.

2. On clicking on this button, the Yelp App sends the following https request to accounts.google.com.

https://accounts.google.com/o/oauth2/v2/auth?client_id=yelp123&redirect_uri="https://yelp.com/callback"&scope=contacts&response_type=code&state=foobar

Here we see some additional OAuth 2.0 terminology,

Redirect URI: The call back URI that the authorization server calls once it has finished processing.
Scope: This specifies at a granular level, the “scope” of the access to the resource i.e. are we requesting authorization to read the resources, modify the resources etc.
Response Type: Which specifies that the Authorization server will provide the Client with an “Authorization Code” , which the Client will exchange for an access-token (using the back-channel). More on this later.

3. Joe is directed to the accounts.google.com page and prompted to login to accounts.google.com using his google credentials.

4. Based on the “Scope” parameters in the original request, the Authorization server (i.e. accounts.google.com) constructs a “Consent” page, which describes to the “resource owner” what exactly the “Client” is wanting to access. At this point the “Client” can click Yes/No on the consent page to grant consent to the appropriate resource.

In our example the Consent page will say “Yelp is requesting read access to your google.contacts, do you Consent (y/n)?”

5. Once the “resource owner” clicks on “yes” on the “Consent” page, the Authorization server returns an “Authorization Code” to the “Client” and calls the “redirect URI” specified in the initial request.

6. The “Client” now uses the “authorization code” sent by the “Authorization server” and using a back-channel communication, exchanges the “authorization code” for an “access token” from the “Authorization Server”.

The back-channel communication is communication sent out by web server to web server, (vs. front-end channel communication, which is communication between a browser and a web server).

Thus, the “authorization code” is received on the front channel communication i.e. by the browser to web server. But to add that additional layer of security the “authorization code” is then used by the “Client” web server, and exchanged for an “access-token” from the “authorization server” by the “client” web server.

7. Once the “Client” has the “access token” from the “authorization server” the client can use this “access token” to access google.contacts.

This completes the “OAuth 2.0 Authorization Code” process flow, and the “Client” can now access the “resource owners” resources on the “resource server”.

OAuth 2.0 Implicit Code Flow

The other commonly used OAuth 2.0 process flow is called the “Implicit Code flow” process flow. This flow is used when the “Client” does not have a web server (the client may be a pure javascript app, a pure Angular or a pure React App). In this flow the only difference is that the “Authorization Server” returns the “access token” directly to the “client” (instead of first returning an authorization code, that must be exchanged for an access token). This is done since a pure javascript app does not have a web server to make the back channel call to exchange the “authorization code” for an “access token”. The “OAuth 2.0 Implicit Code flow” is some what less secure, since it does not involve the back-channel exchange, however is the only alternative in case of pure javascript apps (that do not have a web server).

Federated Authentication

Federated Authentication is the ability for you to login to an App (eg. Spotify or Yelp) using your facebook login. In this case Spotify or Yelp “federates” the ability to identify the user to facebook.

Note that Federated Authentication is different from Delegated Authorization.

Federated Authentication allows you to login to a site using your facebook or google account.

Delegated Authorization is the ability of an external app to access resources. This use case would be for example Spotify trying to access your google contacts list to import it into Spotify.

OAuth 2.0 was designed primarily for delegated authorization, OpenId Connect is the few additional steps added over OAuth 2.0 to extend OAuth 2.0 for Federated Authentication.

OpenId Connect Process Flow

The OpenId Connect process flow is the same as the OAuth 2.0 authorization process flow with the following additions.

In addition to the access-token, an Id-token is returned by the authorization server.
Userinfo end point for getting more user information (if the Id token is not sufficient)
“openid” is passed as a parameter in the Scope during the initial call to the Authorization server.

So if an Authorization server is also set up for OpenId Connect, you can in addition to exchanging the authorization code for an access-token, also get an id-token, which can be used for user “authentication”.

The id-token is the added piece in OpenId Connect, that allows the the OAuth 2.0 flow to be used for Federated Authentication.

The “id-token” is typically returned in JWT (JSON Web Token) format.

OpenId Connect vs. SAML

There are two popular industry standards for Federated Authentication. SAML (or Security Assertion Markup Language) flow, and OpenId Connect.

OpenId Connect is built on the process flows of OAuth 2.0 and typically uses JWT (JSON Web token) format for the id-token.
SAML flow is independent of OAuth 2.0, and relies on the exchange of messages for authentication in XML SAML format (instead of JWT format).

Both flows allow for SSO (Single Sign On), i.e. the ability to log into a website using your login credentials from a different site (eg. facebook login or google login).

Can you combine OpenId Connect and SAML?

Both these authentication flows are independent of each other, and all fully complete in terms of achieving authentication for single sign on. So while in theory you could combine elements from one into another , there is no real reason to do so. They are just two independent and separate ways of achieving federated authentication.

OpenId connect is newer and built on the OAuth 2.0 process flow. It is tried and tested and typically used in consumer websites, web apps and mobile apps.

SAML is its older cousin, and typically used in enterprise settings eg. allowing single sign on to multiple applications within an enterprise using our Active Directory login.

Found this post useful? Hit the 👏 button below to show how much you liked it :)