oAuth: 2.0
What is OAuth?
From the official definition
It allows authorization flows for web applications, desktop applications, mobile apps etc.
Key components
The 3 key components of OAuth are as under
A. Roles/Actors
oAuth RFC defines 4 roles
1. resource owner
An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. It can be a company as well.
2. resource server
The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
3. client
An application making protected resource requests on behalf of the resource owner and with its authorization
. The term “client” does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
OAuth defines two client types, based on their ability to authenticate securely with the authorization server
(i.e., ability to maintain the confidentiality of their client credentials):
confidential
Clients capable of maintaining the confidentiality of their credentials (e.g., 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.
4. authorization server
The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization
.
B. Scopes and Consent
Scopes is what you see when you are shown a confirmation dialog while requesting service from a provider that initiates the flow. These are coded by the application developer when writing the application. Scopes decouple authorization
policy decisions from enforcement
.
C. Tokens
To request an access token, the client obtains authorization
from the resource owner
. The authorization is expressed in the form of an authorization grant
, which the client uses to request the access token
. OAuth defines four grant types:
authorization code
,implicit
,resource owner
password credentials
client credentials
.
It also provides an extension mechanism for defining additional grant types
.
Access tokens
Access tokens are credentials used to access protected resources.
An access token is a string representing an authorization
issued 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. The access token provides an abstraction layer, replacing different authorization
constructs (e.g., username and password) with a single token understood by the resource server.
Refresh Tokens
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.
Flows
Obtaining authorization and subsequent token has 4 main flows
Implicit flow/grant
- All communication happens through browser
- Optimized for public clients
- An access token is returned directly from the
authorization request
(front channel only). - Does not support issuance of refresh tokens.
- These clients are typically implemented in a browser using a scripting language such as
JavaScript
. (SPA’s) - The implicit grant type does not include
client authentication
and relies on the presence of theresource owner
and the registration of theredirection URI
.
Authorization code flow/3 legged flow
- The authorization code grant type is used to obtain both
access tokens
andrefresh tokens
and is optimized forconfidential clients
. - Uses the front channel for
authorization
and theback channel
fortokens
.
Client credential flow
- For server to server scenarios
- Client is confidential
Resource Owner Password flow
- The resource owner password credentials is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application
- It is suitable for clients capable of obtaining the resource owner’s credentials (username and password, typically using an interactive form).