Oauth 2.0

1. not used for authentication
2. not really a authorisation protocol
3. it is a delegated authority

Let's say that you as a user of two applications want to share data between two applications (App-2 to App-1) and your data is protected behind login creds. In this case you need to share the creds of App-2 into App-1.

If you share creds then it has a drawback that App-1 has access to all your data and creds are not secure anymore. You can’t decide what data should be shared and what should not.

Oauth is designed to solve the above drawback. When we use oauth 2.0 and you want to login to App-1 then it redirects you to App-2 for login and proves its identity(integration). Now user is logging into App-2 and App-1 never sees the password. During login, the user can review the access level App-1 is requesting before approving the integration. Once user approves then a token stamped with access level is used by App-1 to retrieve data from App-2.

Benefits of using Oauth 2.0 over sharing creds:

• Users can verify and change the level of access granted to Another application
• Users can change the password without revoking access.
• Users can revoke access anytime.

• RO: Who owns the data
• Client: To whom, the user delegate the authority
• AS: Generates the authorisation token
• RS: Where user data resides

Authorization & Resource Server can be hosted on the same server or a different server.

How outlook client get data from the Office365 server

Here AS & RS both are hosted on Office365 server.

When outlook client tries to get emails from RS for the very first time, the request does not contain any token. RS redirect user to AS. AS display the authentication screen where user enters the creds. Once authenticated, AS provides Access Token & Refresh Token to client. Client again sends the request to RS for emails with an Access token and gets emails.

It means the user has delegated authority to outlook client to sync emails.

Token Expiry Time

TTL (Time to live) or expiry time for Access & Refresh token depends upon the configuration of a server. Generally, Access token TTL is 1 hour and Refresh Token TTL is 14–90 days. If user has not used the application for up to 14 days then refresh token will expire. If user uses the application every day then refresh token will be valid for 90 days.

Server to Server

In this example, We have App1(client) and App2(AS & RS both). Before App1 can do any valid communication with App2, Admin of both apps should talk to each other.

Admin of App1 must register his app1 on App2 server. For registration name & callback URL of App1 are required. Admin of App2 generates client-id & Client Secret which App1 should use during its communication with App2. Id & secret of client can be generated via configuration of app2.

Flow starts with user’s browser which tries to access App1, user is navigated to app2 for authentication. This redirection contains:

• Client Id
• Redirect Uri
• Response Type: Code
• Scope: Profile Contacts

Response Type Code indicates that App1 need an authorisation code. Scope indicates the level of access App1 is requesting. Here App1 needs access to the profile and contacts.

After authentication, user is presented with the Scope, Asking permission to allow app1. Once allowed, user is navigated back to App1 callback URL with the Authorisation code.

App1 sends the Authorisation code back to App2 with the below headers:

• Code: Actual Authorisation code received in the above steps.
• Client Id
• Client Secret
• Grant Type: Authorisation Code(Constant String). Meaning App1 wants to exchange the Authorisation code with Access Token

App2 generates and send back:

• Access Token
• Refresh token
• Expiry
• Token type: BEARER

Now, App1 can access RS data with an Access token. The access token is stamped with the privilege to access profile & contacts.

Why did we exchange the Authorization code with Access Token and not directly issue Access token at first step?

It is a matter of security. Since first communication was happening via client browser and a malicious user might get the access token. Front & Back Channel adds a layer of security.