OAuth 2.0

• We login using Third-party providers using Google, LinkedIn, Twitter,GitHub
• It is also called as access without password.
• Actors involved in OAuth are as follows
• User
• Client
• Resource server
• Third-party app
• Users data
• Authorisation server
• Resource owner.
• Application asks User for confirmation of access and authorisation via third-party provider app to which user has already registered on.
• The application based on user response connect to the authorisation server of the third-party app.
• Authorisation server asks user for approval of sharing its information to the application.
• User approves/rejects The authorisation of information to be Shared by authorisation server.
• The user action Goes back to the authorisation server of the authorisation app and the authorisation server sends a token(authorisation code) Back to the App requesting information depending on user action.
• The application then asks for access token Based on the authorisation token received from authorisation server.
• The app can now access user respective resources based on access token received.
• We define scope in OAuth request I.e. Information we are looking for like Profile/File/contact, et cetera.
• 0Auth 2.0 Is also called as delegation protocol as it provides temporary access to resource server.
• We also send a client ID to the authorisation server.
• OAuth stands for Open authorisation.
• It is an authorisation framework.
• Enables Secure third-party access to user protected data.
• Authorisation grant type Is a mechanism used by client to get access token.
• Authorisation grant types
• Authorisation Code Grant
• Registration process
• A post request Is sent to authorisation server on /register API, which contains client name and redirect URL as parameters.
• There may be at most three redirect URL’s
• As a response to above, request, the authorisation server sends back Client, a client name, client ID, and client secret.
• This registers the client to the authorisation server and authenticate it.
• Fetch the Authorisation code.
• The user when clicks on client side to start the authorisation process, a GET request is sent by client to authorisation server on /authorise api with para metres response type as “code”, Client ID, redirect URL, Scope, state
• Response type specifies the desired response type from the server. This is a mandatory field.
• Client ID is the ID received during registration process and is mandatory.
• Redirect URI Is optional if not sent any one provided during registration is used, and if provided must be one of the three provided during registration.
• Scope is the information for which access is needed.
• State is some random value, which helps in protecting CSRF(Cross site request forgery). This is also not mandatory.
• As a response to above request, the user is presented with oAuth page which Authenticates User on the OAuth server. The user may need to log into OAuth server. The user provides consent for information access.
• The client is then taken to the redirect URL With authorisation code along along with state.
• The client matches the state with state sent if it is same, it proceeds with the request else it discard the request.
• Fetch the authorisation token
• This is another Post request to token API, which sends “authorisation_code” As grant type, client auth code as code, The redirect URI, The client ID and client secret.
• As a response, we get access token Through which we can access the protective data, it is a short lived token, Which generally expires in 3600 seconds or one hour. We also get a refresh token and token type I.e. Bearer
• If above main token expires We can generate a new token using refresh token.
• Our token can be A JWT token or a plane string itself.
• Using the token, the client can accessed the data.
• Generate a new token/Refresh token grant
• We send a post request to token API with grant type as “refresh_token” And refresh_token and redirect url and Client ID and client secret.
• In response, we get a new access token And a new refresh token.

• Implicit grant
• We send a get request to authorisation API with response type as “token”, And client ID, and redirect_url And scope and state.
• It directly provides the access token without authorisation token and is not recommended.
• In response on redirect URL We get access token, Token type and expires in.
• There is no refresh token in implicit grant.
• Resource owner, Password credentials grant
• We send a Post request to token API with grant type as “password” With client ID, client, secret, resource owner username, resource owner password, And scope.
• In the response, it returns, the access token, Token type, expires_in, and refresh_token.
• At the time of refresh, we don’t need to pass username and password.
• There is no need to call authorisation API.
• Client credential grant
• In this, we pass a post request to token URL with grant type as “ Client_ Credentials”, Client ID and client secret and scope.
• In response, we get access token and token type and expires.
• This is when resource owner is itself the client.
• There is no reference token required here.
• No authorisation code is required here.
• CSRF attack(Cross site request forgery)
• The attacker may intercept request and send its own authorisation code.
• User gets authenticated with attackers account.
• Any activity user will perform will be perform performed by attacker account.
• That is why state comparison is needed during authorisation of user.
• Bearer Is a security mechanism, And it means that client should add the token in the authorisation header, whenever it wants to access the protected resources.
• So basically, there are three URL in the OAuth process
• Register API, which is the post request
• Authorisation API, which is get request
• response_type
• Token API, which is again, Post request
• grant_type