OAuth2.0 Tutorial - PART - 4

 

Delegated Authorization V/S Federated Authentication

Delegated Authorisation

Let’s think about xyz owns certain resources(eg. xyz’s contact list) that are hosted on some server (eg. google.contacts server). Now, xyz 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. Xyz needs some mechanism by which he can “authorise”, the Yelp app to access his contacts on the google.contacts server.

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

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

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. Federated Authentication is different from Delegated Authorisation. Federated Authentication allows you to login to a site using your facebook or google account.

Delegated Authorisation 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 Roles

•OAuth defines four roles:

•Resource Owner

•Client

•Resource Server

•Authorisation Server

Resource Owner: User

The resource owner is the user who authorises an application to access their

account. The application's access to the user's account is limited to the "scope" of

the authorisation granted (e.g. read or write access).

Resource / Authorisation Server: API

The resource server hosts the protected user accounts, and the authorisation

server verifies the identity of the user then issues access tokens to the application.

From an application developer's point of view, a service's API fulfils both the

resource and authorisation server roles. We will refer to both of these roles

combined, as the Service or API role.

Client: Application

The client is the application that wants to access the user's account. Before it may

do so, it must be authorised by the user, and the authorisation must be validated

by the API.