Demystifying OAuth 2.0 and OpenId Connect (and SAML)

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”.

• Re