Oauth2.0 for Authorization

Oauth2.0 industry standard protocol for authorization. Using OAuth 2.0 we can provide limited access over resources.

Before getting into the introduction and details of OAuth 2.0, let us get familiar with some terminologies that you will come across often in this article:

Roles: -

1) Resource Owner — End user or machine

2) Resource Server — Server hosting the protected resources (i.e. web application, SPA, Apis services)

3) Client — Web Application, Native application, machine (i.e. Api or service or user-agent based) which wants to access resource.

4) Authorization server: — Server issuing access token to the client.

Endpoints: Url endpoints to get authentication, authorization tokens.

1) Authorization endpoints ( https//xyz/services/oauth2/authorize )Endpoint that provides the authorization code

2) Token endpoints ( https//xyz/ services/oauth2/token )Endpoint that gives us a token after authentication

Authorization grants: — Credential representing the resource owner’s authorization to access protected resources. Before using any of the flows, we have to register our resources on IDP server to build trust with applications or resources.

1) Authorization Code Grant

2) Implicit Grant

3) Resource owner password credential Grant

4) Client Credential Grant

1) Authorization Code Grant: — We should use this grant when we are trying to access the resources from a WEB APPLICATION. For example, when login into any web application using FB, Google, LinkedIn, etc. we are actually requesting the servers to access the relevant resources.

Instead of requesting for authorization directly from a resource owner (i.e. user), the client application (e.g. web application) directs the resource owner to an authorization server, which in turn directs the resource owner back to client application with authorization code [step1 below].

After getting the authorization code, resource owner has to login on IDP server and then the client application will get an authorization code. The resource owner’s credential is never shared with the client application.

Request_Header 1: — First we hit authorize end point to get Authorization Code:

{
url:’https://AUTHORIZATION_DOMAIN/authorize?

Here, Scope specify the level of access that the application is requesting (e.g. read )

Response 1: — After invoking authorization endpoint, we will get a code that looks like below:

{
code=AwABAAAAvPM1KaLEMPGYuNHSUYBrq…
&state=12345
}

Request Header 2: — After hitting authorize endpoint, we have to hit token endpoint to get token by giving Code.

{

While hitting we pass the following data

1. grant_type to specify which grant type we are using.

2. Client_id: client id of redirect application

3. Client_secret of redirect application

4. Code is the authorization code which we got after hitting authorize endpoint.

5. Redirect uri is uri where our IDP will redirect after authorization.

Response 2 :-

{

Here we have following data: -

1. access_token for authorization token

2. refresh_token for refresh token before expire

3. id_token for authentication token. Obtain this token using OpenIDConnect

4. token_type is telling whether it is bearer or mac token

5. expires in time within token

2) Implicit Grant: -

Used for user-agent based clients (e.g. SPAs, mobile native or hybrid app) that can’t keep “client_secret” because of the application code and storage being easily accessible .it doesn’t take responsibility of issuing refresh tokens because of security reasons. However, there are other mechanisms to get updated access tokens.

Request: -

{
url:’http://AUTHORISATION_DOMAIN/authorize?

Response:

{

Authorization server MUST NOT issue a refresh token because of security reason.

The authorization server validates the request to ensure validity of all required parameters. It also checks if the redirect_uri is similar to the registered URI or not. Upon successful validation of the request, the IDP will initiate the process of returning an access token to the client.

3)Resource owner password credential: -

This grant is used for trusted applications (web or native mobile) which are owned by the service itself. In this flow, the Resource owner (e.g. user) has a trust relationship with the client such as a device operating system or a highly privileged application.

Request: -

{url:’http://AUTHORISATION_DOMAIN/oauth/token',

Response :

{

4)Client credential grant: — This flow is only for machine to machine communications like services to services, apis to apis or bots to bots.

Request: -

{
url:’http://AUTHORISATION_DOMAIN/oauth/token',

Response :

{

In this flow no refresh token is generated, however there is way to get new access_token before the current one expires. The authorization server(IDP) will return an error response if the request fails or is invalid.

Conclusion: OAuth 2.0 is only for authorization. You need to use OpenID Connect protocol for authentication.

Please watch out for my next security update where I will go into details of implementing each flow and also talk about defining your custom authorization grant types, endpoints response types and error codes.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kumar Shivam

Technical Consultant | Passionate about exploring new Technology | Cyber Security Enthusiast | Technical Blogger | Problem Solver