OAUTH 2.0 (A protocol for Authorization in the Applications)
OAUTH 2.0 (A protocol for Authorization in the Applications)
OAuth is an Open Standard protocol designed for authenticating or authorizing the user into the Application. The Protocol is designed to gain access into the application or grant website for particular resources that user or application is requesting.
History
OAuth has begun in November 2006 when Blaine Cook was developing the OpenID protocol. In meanwhile Gnolia needs a solution to access Dashboard resources from his member’s OpenID account to authorize their service from Twitter. They come to know there was no Standard Protocol present.
The small group of OAuth members was created in April 2007 to make a proposal for an open Protocol. With DeWitt Clinton from Google, The first draft was released on December 2007 (OAuth Core 1.0).
The OAuth 1.0 protocol was published as RFC 5849, in April 2010.
The OAuth 2.0 framework was published as RFC 6749, in October 2012.
Overview
The OAuth 2.0 Protocol defines a Client (any client that want resources from Applications), Authorization Server (responsible for authorizing client user), Resource Server (User Client-side Application for requesting tokens and authenticating them with Authorization server).
The key concepts are as follows:
- Resource Owner – An entity capable of granting access to protected resources.
- Resource Server – A server that will be requesting new access tokens from the authorization server.
- Authorization Server – A server that authorizes the client, issues a token for that client user.
- Client – A user that is requesting to access resources (any sort of information).
You often came across this dialogue box when you social sign in with Google, Facebook or Twitter from other application. This is simple approval from the user to ask for, Would you like you this information to access to Other App? (Form which you have requested to Social Sign in). And when you say Allow, the requested application has the right to access or modify your content to requested Application (Facebook or Twitter). This (image) is nothing but OAuth Approval for user side, do you want to allow this after a successful login at the social site (for instance).
Say for example you visit www.slack.com for creating your slack account, you will notice application provides to login with other Email accounts, like Gmail, Yahoo, etc. That is what sort of OAuth Protocol. Another application requests for some sort of information from other domains to have access.
The simple Facebook flow architecture is depicted below with all overall process-
When the user requested to get into App the application wants some sort of data from Facebook. The user tries to get in App has redirected to the site.
This URL is actual Authorization server host where we will be able to get an Access token or Authorization codes,
Where Params are as follows –
- respose_type – response Type can be code, offline, access_token. The code is used to get the authorization code from the Authorization server, Offline access is used to get refresh_token also in the response, the access_token is used to directly get the access_token in the response. (required)
- Client_id – is a unique identification for Client (in our case, the App) (required)
- Redirect_uri – redirect URI is redirection after authenticating the facebook user credential (required).
- Scope – the scope is resources that need to access like Use Facebook POST feature, update user details, messaging from App (required)
- State – the state is server-side code for internal security purposes.
As you can see, Facebook will show login page to login, after you authenticated on Facebook the page will get redirect to redirect_uri. The redirected will be like.
Where code is nothing but the key to getting an access_token from Facebook and the state is security key that is passed when App has redirected to Facebook (should be same).
After this process, the Application will call Internal API to get access_token from Facebook.
POST https://api.authorization-server.com/token grant_type=authorization_code& code=AUTH_CODE_HERE& redirect_uri=REDIRECT_URI& client_id=CLIENT_ID This is Post request that is to be made to have an access_token.
This is the response where access_token is retrieved and its expiry time (in seconds). And refresh_token is to get new access_token when it is expired. The token_type is Bearer meaning it an Authorization Header method.
{ "access_token":"RsT5OjbzRn430zqMLgV3Ia", "expires_in":3600, “refresh_token”: “asSkUTIn344xmbGvVFchbAaoeEi”, “token_type”: “Bearer” }
And that’s all process goes under the hood for Authenticating the user (that is what OAuth 2.0).
There is amazing presentation from Okta on Youtube on OAuth and OpenID
The IETF RFC is available under 6749.
The Protocol Flow Architecture
This pretty explains itself what will go under the hood.
- The first step, user redirected to the authorization server.
- The user enters its details.
- Google prompts to do you want Allow Yelp Application to authorize.
- When the user authorizes this user get back to yelp.com with redirect URI callback name.
- And then This is talking to the Authorization Server to get accounts.google.com details.
The Reference Source found for OAuth 2.0 –