Skip to main content

NoSQL Databases

SSD_OAuth 2.0

This blog post will give a brief description about OAuth 2.0


What is OAuth 2.0?

   OAuth 2.0 is a (Open Authorization) is a framework that give users the ability to grant access to their information stored in one place, from another place. To understand what is OAuth first we need to understand the main roles, grant types and the types of tokens.

Roles

   Roles are used to define and separate entities which are involved in a request. Mainly there are four roles.

  1. The Client - The client is the third party application which tries t access the user account. This can be either a website or a application.

  2. The Resource Server - Resource server is the place which stores the user's information

  3. The Authorization Server - This is the server which approves or denies the request. The authorization server produces the access token to the client.

  4. The Resource Owner - Resource owner grants access to the requested data.

Grant Types

    Grant types are the flow of obtaining the access token. A grant represents the user's permission to access their token. Mainly there are four main grant types.

  1. Authorization Code Grant Type - Used by the web applications which are executing on the       server using the PKCE (Proof Key for Code Exchange) method.

  2. Implicit Grant Type - Used by the application which are built using JavaScript or single page applications which are executing on the user's browser.

  3. Resource Owner Password Credentials - Used by the applications which highly trusted. 

  4. Client Credentials - Resource owner grants access to the requested data.


Access Tokens

    The access tokens represents the authorization to access the Resource Owner's information which are on the resource server. On an access token there is an expiry time. Its because any malicious actions are getting limited by doing so.



Generic OAuth flow


Refresh Tokens

    Refresh tokens are a special kind of token that can be used to obtain a renewed access token that allows accessing a protected resource at any time. We can request new access tokens until the refresh tokens are blacklisted.

Sample Application

   Below I have implemented a sample application using java to demonstrate the process of a OAuth 2.0.

   The sample application will be retrieving the details such as name, email, image, age from the google once a user login to the application using the google credentials. In order to build the below application we need to obtain the secret key and the API key from google developers console

  After login to the console click on the dashboard and the create a new project.


After creating the project select the relevant project from the drop down list and click on the 'credentials'. On the dropdown select 'OAuth client ID'


On the next window select the 'configure consent screen' and provide the required data.



     Then you will obtain the 'client ID' and the 'secret key' which are needed to create the sample application. 

I have used the java and jsp technologies to built the sample app. The grant type which I have used is 'Authorization Code Grant Type'.


The steps are as follows:

A) The client redirects the user-agent (usually a browser) to the login page of the authorization server.

B) The authorization server presents the login page to the resource owner via the user-agent (if the resource owner is not already authenticated to the authorization server).

C/D) The resource owner supplies credentials to the login page. This establishes the identity of the resource owner (authentication).

E) The authorization server requests access to resource-owner data on behalf of the client

F/G) The resource owner grants the client authorization to access resource owner data.

H/I) The authorization server redirects the user-agent to the callback URL supplied by the client in the call (which must match the redirect_uri supplied when the client registered with the authorization server). Once the user-agent has been redirected, the user will see the authorization code, which will be in the form of a URL parameter.

J) The client uses the authorization code, along with its client credentials, to request an access token (with an optional refresh token) from the authorization server.

K) The authorization server returns an access token to the client, along with the optional refresh token. The authorization token can now be used to request access to protected resources from the resource server.

GoogleAuthenticator.java













































Comments

Popular posts from this blog

SSD

Cross Site Request Forgery             Cross-Site Request Forgery (CSRF) is an assault that powers an end client to execute undesirable activities on a web application in which they're at present verified. CSRF assaults particularly target state-evolving demands, not robbery of information, since the assailant has no real way to see the reaction to the produced demand. With a little help of social designing, (for example, sending a connection through email or talk), an attacker may trap the clients of a web application into executing activities of the assailant's picking. On the off chance that the injured individual is a typical client, a fruitful CSRF assault can compel the client to perform state changing solicitations like exchanging reserves, changing their email address, ect. On the off chance that the unfortunate casualty is a managerial record,CSRF can compromise the entire web application. What is CSRF and how it works ?     A...

EclEmma for code coverage

What is code coverage?                  Code coverage analysis is a structural testing technique (AKA glass box testing and white box testing). Structural testing is also called path testing since you choose test cases that cause paths to be taken through the structure of the program.  Code coverage is a measure used to describe the degree to which the source code  of a program  is executed when a particular test suits  runs. A program with high code coverage, measured as a percentage, has had more of its source code executed during testing which suggests it has a lower chance of containing undetected software bugs  compared to a program with low code coverage. What is EclEmma? This is a plugin for Eclipse which will shows you the coverage of a specific test set. You can run these on you Junit tests to check which statements are executed and which are not. there will be three main colors after you run this...