What is OAuth 2

OAuth 2 provides authorization flows for web and desktop applications, and mobile devices. It is an authorization framework that enables applications to obtain limited access or information to user accounts on an HTTP service.

It is an open authorization protocol which enables applications to access each others data. For instance, a game application can access a users data in the Facebook application, or a location based application can access the user data of the Foursquare application etc.

We will now discuss OAuth 2's Role Types and Authorization grant types.

OAuth Roles

• Resource Owner
• Resource Server
• Authorization Server
• Client

Authorization Grant

The authorization grant type depends on the method used by the application to request authorization, and the grant types supported by the API. OAuth 2 have four grant types:

• Authorization Code: used with server-side Applications
• Implicit: used with Mobile Apps or Web Applications (applications that run on the user's device)
• Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself
• Client Credentials:used with Applications API access

Now let's discuss the above following heads in more details.

OAuth Roles > Resource Owner(user)

The resource owner is the user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g. read or write access).

OAuth Roles > Resource Server(API)

The resource server hosts the protected user accounts.

OAuth Roles > Authorization Server

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

From developer's point of view a service's API fulfills both the resource and authorization server roles.

OAuth Roles > Client

The client is the application that wants to access the user's account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.

Authorization Grant > Authorization Code

The authorization code grant type is the most commonly used because it is optimized for server-side applications, where source code is not publicly exposed, and Client Secret confidentiality can be maintained. This is a redirection-based flow, which means that the application must be capable of interacting with the user-agent (i.e. the user's web browser) and receiving API authorization codes that are routed through the user-agent.

Authorization Grant > Implicit

The implicit grant type is used for mobile apps and web applications (i.e. applications that run in a web browser), where the client secret confidentiality is not guaranteed. The implicit grant type is also a redirection-based flow but the access token is given to the user-agent to forward to the application, so it may be exposed to the user and other applications on the user's device. Also, this flow does not authenticate the identity of the application, and relies on the redirect URI (that was registered with the service) to serve this purpose.

The implicit grant type does not support refresh tokens.

The implicit grant flow basically works as follows: the user is asked to authorize the application, then the authorization server passes the access token back to the user-agent, which passes it to the application. If you are curious about the details, read on.

Authorization Grant > Resource Owner Password Credentials

With the resource owner password credentials grant type, the user provides their service credentials (username and password) directly to the application, which uses the credentials to obtain an access token from the service. This grant type should only be enabled on the authorization server if other flows are not viable. Also, it should only be used if the application is trusted by the user (e.g. it is owned by the service, or the user's desktop OS).

Authorization Grant > Client Credentials

The application requests an access token by sending its credentials, its client ID and client secret, to the authorization server. An example POST request might look like:

   https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET