Overview about OAuth2.0

When there was no such thing as OAuth 2.0

If you’re a very first beginner to the OAuth 2.0, you need to look back in history, when there was no such thing as OAuth 2.0 before dig deep into the concepts.

Let’s take an example. Back in the day, if you wanted to find your Facebook friends on ABC application, you’d have to provide username and password. Then, the application logged into your Facebook account on behalf of you, went through your friend list and do something with that data. That means, you would need to give your sensitive credentials to the application.

There are a few reasons why following this procedure was a bad idea. The main reasons are:

• The application has the power to do anything with your Facebook account. They are able to share post, change user details, do bad things using the username and more… So besides only requiring access to friends list you have given application access to everything related to your Facebook account.
• Application may store your password (at least for a short amount of time), and may handle your credentials with utmost care. You have no control over it!
• You have to change your Facebook password if application ever gets hacked
• Only way to revoke access for the application is by changing your Facebook password

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

High level solution architecture:

Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token — a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

OAuth2 components

The following summarizes several components that will be used when implementing OAuth2.

1. Authorization Code

A code that, when combined with the Client Secret, allows the Client Application to request an Access Token. This value is provided by the OAuth2 API. An Authorization Code may only be used once and has a lifespan of 60 seconds.

2. Access Token

A token that, when combined with the Client Secret, allows the Client Application to access data or interact with a Bazaarvoice service on behalf of a user. The Access Token is provided by the OAuth2 API and has a lifespan of 60 minutes.

3. Refresh Token

A token that, when combined with the Client Secret, can be used to request a new Access Token. Refresh tokens have unlimited lifetime as long as they are used at least every 7 days.

4. Client Secret

A value used to verify the identity of the Client Application. This value will be provided by Bazaarvoice when the Client Application is registered.

⚠ The value should not be exposed to the public.

5. Client ID

A value used to identify the Client Application. This value will be provided by Bazaarvoice when the Client Application is registered.

6. Redirect URI

This is a URL that identifies a resource implemented by the Client Application. The Authorization Service will send the User back to this location after the User logs into Bazaarvoice.

⚠ This value must be provided to Bazaarvoice when the Client Application is registered. The Authentication Service will not redirect to unknown locations.

OAuth 2.0 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.

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).

4. authorization server

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Abstract OAuth 2.0 Flow

The abstract OAuth 2.0 flow describes how the four roles listed above interact with each other. Below is a diagram that illustrates this.

1. The IOT device (client) requests authorization from the user (resource owner) to access protected resource.
2. The user authorizes the request, and sends an authorization grant to the client.
3. The client requests access token from authorization server (service provider’s API) using authentication identity and authorization grant received from user.
4. The authorization server (service provider’s API) sends an access token to the client, if the client authentication identity and authorization grant provided is valid. At this point, the IOT device (client) has been authorized.
5. The client requests the protected resource from resource server (service provider’s API) using the access token.
6. The resource server sends protected resource to the client, if the access token is authenticated (valid).