OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, Twitter etc. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. OAuth 2 provides authorization flows for web and desktop applications, and mobile devices.
Roles in Digital world
- Technically, OAuth is an authorization protocol that allows an user to grant limited access on one site to another site without having to expose their credentials.
2. OAuth specifically satisfies purpose for authorization not authentication.
3. OAuth is a pathway created for services trying to access each other on behalf of user.
Suppose a car owner wants to park a car by giving instruction to valet. Generally in real life, expensive cars are being arrived for valet parking, one cannot give master key of car to valet that increases the security risk of accessing internal sections such as trunk/panels that holds confidential things in general. To resolve this, car owner provides a valet key, that has access to ignition only, to be applied only to serve the mentioned purpose. Here, let the Car Owner be “user”, Car as a “car service” and Valet as a “valet service”. User has access to both, car service and valet service. Now valet service needs to access car service to follow instruction given by user. Valet service accesses car service by valet key, can be termed as limited access key, given by user thus satisfying the purpose. Here the protocol via which valet service has limited access of car service is termed as “OAuth” and valet key i.e. limited access key is termed as “Access Token”.
OAuth defines four roles:
- Resource Owner
- Resource Server
- Authorization Server
We will detail each role in the following subsections.
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).
Resource / Authorization Server: API
The resource server hosts the protected user accounts, and the authorization 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 fulfills both the resource and authorization server roles. We will refer to both of these roles combined, as the Service or API role.
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.
Abstract Protocol Flow
Now that you have an idea of what the OAuth roles are, let’s look at a diagram of how they generally interact with each other:
Here is a more detailed explanation of the steps in the diagram:
- The application requests authorization to access service resources from the user
- If the user authorized the request, the application receives an authorization grant
- The application requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant
- If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application. Authorization is complete.
- The application requests the resource from the resource server (API) and presents the access token for authentication
- If the access token is valid, the resource server (API) serves the resource to the application
The actual flow of this process will differ depending on the authorization grant type in use, but this is the general idea. We will explore different grant types in a later section.
Before using OAuth with your application, you must register your application with the service. This is done through a registration form in the “developer” or “API” portion of the service’s website, where you will provide the following information (and probably details about your application):
- Application Name
- Application Website
- Redirect URI or Callback URL
The redirect URI is where the service will redirect the user after they authorize (or deny) your application, and therefore the part of your application that will handle authorization codes or access tokens.
Client ID and Client Secret
Once your application is registered, the service will issue “client credentials” in the form of a client identifier and a client secret. The Client ID is a publicly exposed string that is used by the service API to identify the application, and is also used to build authorization URLs that are presented to users. The Client Secret is used to authenticate the identity of the application to the service API when the application requests to access a user’s account, and must be kept private between the application and the API.
In the Abstract Protocol Flow above, the first four steps cover obtaining an authorization grant and access token. 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 defines four grant types, each of which is useful in different cases:
- 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
That concludes this OAuth 2 guide. You should now have a good idea of how OAuth 2 works, and when a particular authorization flow should be used.
If you want to learn more about OAuth 2, check out these valuable resources: