OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0
supersedes the work done on the original OAuth protocol created in 2006.
The OAuth 2.0 authorization framework enables
a third-party application to obtain limited access to an HTTP service, either
on behalf of a resource owner by orchestrating an approval interaction between
the resource owner and the HTTP service, or by allowing the third-party
application to obtain access on its own behalf.
OAuth 2.0 Earlier Practices
1. Simple Login: Form-based Authentication
Disadvantages-
- Ensuring security of each login activity
- Maintaining the forms , hashing algorithms , cookies , session
variables etc.
2. Single-Sign-On : SAML (Security Assertion Markup Language)
Security Assertion Markup Language is an open standard for exchanging
authentication and authorization data between parties, in particular, between
an identity provider and a service provider. SAML is an XML-based markup
language for security assertions.
3. Delegated Authorisation
Allowing other websites to access a resource owner’s data stored in some other website without giving the Password.
Earlier Solutions for Delegated Authorization
1. Yelp
This is an
example in which Yelp wanted to solve the issue of delegated authorization and
incorporated a method with which a user could let Yelp access some part of
his/her data from his preferred mail ID by entering their mail ID and Password
for the same.
2. Facebook
This is an
example in which Facebook wanted to solve the issue of delegated authorization
and incorporated a method with which a user could let Facebook access some part
of his/her data from his preferred mail ID by entering their mail ID and
Password for the same.
Issues with Earlier Solutions
In the shown cases, a user will have to just trust Yelp or Facebook and believe that they keep his/her mail ID and password safe and also that they do not access any other information except what they asked for.
These were insecure and bad ways to implement delegated authorization and left the user’s credentials as well as his/her account at risk always.
Solutions for Delegated
Authorization Today
In the given example, the user is asking Google to allow Yelp/Facebook to access only his contacts using Google APIs.
Here, after authenticating the user, Google API will grant access of the user’s contacts to Yelp/Facebook.
A Real Life Example
The following are real-life examples that involve a secure implementation of delegated authorization.
Here, Spotify wants to access some of the user’s Facebook data.
OAuth 2.0 Terminology
Taking an example
of a user trying to login into LinkedIn using Gmail(Google) API and
credentials-
- Resource Owner: The user who is interacting with the application (the user owns the data the application wants to get to)
- Client: The application with which the user is interacting directly (LinkedIn)
- Authorization Server: The server which is used to Authorize the request sent by the client for the user’s data (Gmail)
- Resource Server: The API or the system that actually holds the client’s data (Gmail API )
- Authorization Grant: The entity that proves that permission is granted to the client by the Authorization Server
- Redirect URI: After the Authorization Grant is given by the Authorization Server , it is sent to the client , to the callback address provided by the client, this callback is sometimes known as Redirect URI
- Access Token: It is the key used by the client to access the resources it has been granted access to , at the Resource Server
Channels
There are two
types of channels by which the whole process occurs.
- Front Channel: It is the initial (not so secure) channel between the user’s browser side client and the Authorisation Server.
- Back Channel: It is the highly secure channel between the Client’s Server and the Authorization Server and the Client’s Server and the Resource Server.
Client Types
OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., the ability to maintain the confidentiality of their client credentials):
Confidential: Clients capable of maintaining the confidentiality of their credentials (e.g., the client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.
Public: Clients incapable of
maintaining the confidentiality of their credentials (e.g., clients executing on
the device used by the resource owner, such as an installed native application
or a web browser-based application), and incapable of secure client
authentication via any other means.
Protocol Endpoints
The authorization process utilizes two authorization server endpoints (HTTP resources):
Authorization endpoint — used by the client to obtain authorization
from the resource owner via user-agent redirection.
Token endpoint — used by the client to exchange an authorization grant for an access
token, typically with client authentication.
As well as one
client endpoint:
Redirection endpoint — used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent.
Simple Representation of OAuth 2.0 in Action
Steps:
- Yelp/Facebook wants to access the user’s Gmail contacts, so they give the option to do so using Google’s API
- As soon as the user clicks on Connect with Google, he is redirected to a google endpoint where he is asked to enter his gmail credentials (Authentication)
- When the Authentication is successful, the user is asked whether he
wants to allow Yelp/Facebook to access his data or not - If the user clicks on Yes, he is redirected back to Yelp/Facebook, and Yelp/Facebook is given access to his contacts.
- If the user clicks on No, the access request is terminated.
We can see that the process in which Yelp/Facebook accesses Gmail contacts has dotted lines, which implies that it takes place via the Back Channel.
The solid lines
represent the Front Channel.
OAuth 2.0 Authorisation Grant
An Authorisation Grant is a credential representing the resource owner’s authorization (to access its protected resources) used by the client to obtain an access token.
It has the
following types:
1. Authorisation Code
The authorization code is obtained by using an authorization server as an intermediary between the client and the resource owner.
Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server via its user agent, which in turn directs the resource owner back to the client with the authorization code.
Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization.
Because the resource owner only authenticates with the authorization server, the resource owner’s credentials are never shared with the client.
2. Implicit
The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript.
In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly.
When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client.
3. Resource Owner Password Credentials
The resource
owner password credentials (i.e., username and password) can be used directly
as an authorization grant to obtain an access token. The credentials should
only be used when there is a high degree of trust between the resource owner
and the client, and when other authorization grant types are not available.
4. Client Credentials
The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.
Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.
OAuth 2.0 Access and Refresh Tokens
Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client.
The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).
Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token.
A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client.
The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.
Obtaining Authorisation Example: Authorisation Code Grant
Steps:
- Yelp/Facebook wants to access the user’s gmail contacts, so they give an option to do so using Google’s API.
- As soon as the user clicks on Connect with Google , he is redirected to an Authorisation Server where he is asked to enter his gmail credentials (Authentication). This request also contains the Redirect URI , Response Type and Scope of the request.
- When the Authentication is successful, the user is asked whether he wants to allow Yelp/Facebook to access his data or not.
- If the user clicks on Yes , he is redirected back to Yelp’s/Facebook’s Redirect URI, along with an Authorisation Code.
- If the user clicks on No , the access request is terminated.
- Yelp’s/Facebook’s Server then exchanges the Authorisation Code with the Authorisation Server, and in response, is given an Access Token by the Authorisation Server.
- Yelp’s/Facebook’s Server then sends the data access request to the Resource Server along with the Access Token, and in response, is given access to the data in scope.
Abstract Protocol Flow — OAuth 2.0
Refreshing an Expired Access Token
