Suppose you want to use a great new third party application for Emails that has many awesome features you want. However, this new email application will need access to your Gmail emails in order to work.

Would you give you Gmail password to this third-party application? No.

So, how can this third-party app access our Gmail emails without getting your password?

OAuth 2.0 is one way.

Instead of providing your credentials to this third-party app, you will be redirected to Google OAuth Server. This OAuth Server will accept your Gmail credentials and provide a temporary Access Token to the Third-party app.

Now the third-party app can use this Access Token and access only your Gmail emails. The app cannot use this token to access any other data like your Google Drive. Also this Access Token has a validity after which the token will expire and will have to be re-generated.

Part 1: OAuth Actors

Part 2: OAuth EndPoints

Part 3: OAuth Grant Types

Part 4: OAuth Flows – Authorization Code Flow

Part 1: OAuth Actors

Actors	Role
Resource Owner	1. owns resources – like email 2. owns login credentials 3. delegates access to Third-party application
Client (Third-party application)	1. wants to get access to resources to provide some functionality 2. holds access tokens 3. ideally should not hold password of resource owner 4. identified via ClientI D and Client Secret
OAuth Servers	1. Login Page component 2. LDAP Server to validate user password 3. Consent Page component 4. Token Database component 5. Exposes 2 enpoints

Part 2: OAuth EndPoints

Provider	HTTP Header	HTTP Method	EndPoint	Inputs
OAuth Server	none	GET	/authorize	state  = used to correlate which response maps to which /auth request – can contain any random string (optional) scope = defines type of resources requested by client application (mandatory) response_type =  code (for Authorization Code Grant) | token (for Implicit Grant) (mandatory) client_id = identification of client (mandatory) redirect_uri = redirect endpoint to which result of /authorize is sent to  using query parameters (mandatory)
Client		GET	/redirect	state = receives  state provided to the /authorize endpoint scope  = receives  scope provided to the /authorize endpoint code  = receives  code generated from the /authorize endpoint
OAuth Server	Authorization: Basic {clientID: clientSecret}	POST	/token	grant_type  = authorization_code = Authorization Code Grant password = Resource Owner Password Credentials Grant client_credentials = Client Credentials Grant” client_id  = identification of client client_secret  = only for Client Credentials Grant username  = only for Resource Owner Password Credentials Grant password  = only for Resource Owner Password Credentials Grant code  = only for Authorization Code Grant value of authorization code recieved from /authorize redirect_uri = only for Authorization Code Grant value of the redirect_uri parameter passed to /authorize
OAuth Server			/verify	only internally accessible by Resource Server. checks if Access Token is valid or not
Resource Server	Authorization: Bearer {AccessToken}		/api

Part 3: OAuth Grant Types

Grant Type	EndPoint	Input	Return	When to Use
Authorization Code Grant	/authorize	response_type=code client_id=xxxxxxxxxxxxxx	returns Authorization Code	Use when the Client is a web app executing on the server
Authorization Code Grant	/token	grant_type=authorization_code code=xxxxxxxxxxxxxxxx	returns Access Token + Refresh Token	Use when the Client is a web app executing on the server
Implicit Grant	/authorize	response_type=token client_id=xxxxxxxxxxxxxx	returns Access Token	Use when the Client is a Single-Page App running in a browser using a scripting language like JavaScript
Client Credentials Grant	/token	grant_type=client_credentials client_secret=xxxxxxxxxxxxx	returns Access Token + Refresh Token	Use when the Client is also the Resource Owner. machine-to-machine authorization
Resource Owner Password Credentials Grant	/token	grant_type=password username=xxxxxxxxxxxxx password=xxxxxxxxxxxxx	returns Access Token + Refresh Token	Use when the Client absolutely trusted with user credentials. If redirect-based flows are not possible.
Authorization Code Flow with Proof Key for Code Exchange (PKCE)

Part 4: OAuth Authorization Code Flow

Resource Owner	Client	Request Information	OAuth Server	Resource Server
(1) Hit Login link with Client ——————–|>	(2) Send Auth request to OAuth Server ——————–|>	GET /authorize ?response_type=code &scope=name,email &client_id=ddddddd &state=req1 &redirect_uri=https://client.com/redirect Host: oauth.server.com ——————–|>	(3) Matches client_id and redirect_uri of registered client
(6) Gets Login Page from OAuth Server	(5) Redirect <|--------------------	Login Page <|--------------------	(4) Send Redirect to Login Page <|--------------------
(7) Enter Login Credentials. Send directly to OAuth Server ——————–|>		Filled Login Page ——————–|>	(8) Validates Credentials in LDAP Source configured
(10) Gets Consent Page from OAuth Server		Consent Page <|--------------------	(9) Send Consent Page with Scopes <|--------------------
(11) Give Consent. Send directly to OAuth Server ——————–|>		Consent Provided ——————–|>	(12) Validates consent.
(14) Owner Browser receives  Redirect		HTTP/1.1 302 Found Location: https://client.com/redirect? code=ccccc& state=req1 <|--------------------	(13) Send Redirect to Redirect URL <|--------------------
(15) Owner Browser redirects ——————–|>	(16) Client Gets the Authorization Code Sends request to Token Endpoint of OAuth Server ——————–|>	POST /token HTTP/1.1 Host: oauth.server.com Content-Type: application/x-www-form-urlencoded Authorization: Basic xxxclientidxxxclientsecretxxx grant_type=authorization_code &code=ccccc ——————–|>	(17) Validates Authorization Header for Client ID and Client Secret Validates if Authorization Code is valid
	(19) Client receives  the Access Token	HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 {  “access_token”: “ttttttttt”,   “token_type”: “Bearer”,   “expires_in”: 3600,   “refresh_token”: “rrrrrrrr”,   “scope”: “email” } <|--------------------	(18) Create an Access Token and send it back to the Client Scopes are sent if the granted scopes differ from the requested ones. <|--------------------
	(20) Client sends API request to Resource Server ——————–|>	GET /api Authorization: Bearer ttttttttt Host: resource.server.com ——————–|>		(21) receives  API request from Client
(24) Resource Owner receives  the Resource	(23) Client receives  the Resource <|--------------------	Resource <|--------------------		(22) Verify Token with OAuth Server Send the resource back to Client. <|--------------------