oAuth2 : Refresh Token Flow

 https://darutk.medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85 

This is the flow defined in RFC 6749, 6. Refreshing an Access Token. A client application (a) presents a refresh token to a token endpoint and (b) gets a new access token.

https://software-factotum.medium.com/pkce-public-clients-and-refresh-token-d1faa4ef6965 

https://www.youtube.com/watch?v=jcKDsQfBgYY

oAuth 2 : Client Credentials Flow

 

https://www.youtube.com/watch?v=XJuFcXI2v2k 

oAuth2 : Resource Owner Password Credential Flow

 https://darutk.medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85 

https://www.youtube.com/watch?v=CGMiOHrOAYQ 

This is the flow defined in RFC 6749, 4.3. Resource Owner Password Credentials Grant. A client application (a) makes a token request to a token endpoint and (b) gets an access token. In this flow, a client application accepts a user's ID and password although the primary purpose of OAuth 2.0 is to give limited permissions to a client application WITHOUT revealing the user's credentials to the client application.

oAuth2 : PKCE

Why do we need PKCE ? https://www.youtube.com/watch?v=_zWovo2zv6k 

More Details : https://oauth.com/oauth2-servers/pkce/authorization-request/ 

Note : the malicious App and Legimate App both live in the same environment

 https://www.authlete.com/developers/pkce/#2-pkce-authorization-request

PKCE Authorization Request

Include 

1. 'code_challenge' : computed by applying 'code_challenge_method' to 'code_verifier'
2. and optionally with 'code_challenge_method' : can be plain or S256
3. AND code_verifier which is a random string of of [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" and a min of 45 and max of 128 chars

PKCE Authorization Response

PKCE Token Request

Issue Access token

oAuth2 : Implicit Grant

https://darutk.medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85  

https://datatracker.ietf.org/doc/html/rfc6749#section-4.2

https://www.youtube.com/watch?v=fX5U50VGxtg

This is the flow defined in "RFC 6749, 4.2. Implicit Grant". A client application (a) makes an authorization request to an authorization endpoint and (b) gets an access token directly from the authorization endpoint.

https://stackoverflow.com/questions/7522831/what-is-the-purpose-of-the-implicit-grant-authorization-type-in-oauth-2 

In summary difference between "Implicit Grant Flow" & "Authorization Grant flow" is in "implicit grant flow" "access token" directly without client authorization 

Because implicit grant flow is for clients that are implemented entirely using javascript and are running in resource owner's browser. You do not need any server side code to use this flow. Then, if everything happens in resource owner's browser it makes no sense to issue auth code & client secret anymore, because token & client secret will still be shared with resource owner. Including auth code & client secret just makes the flow more complex without adding any more real security.

So the answer on "what has been gained?" is "simplicity".

https://www.youtube.com/watch?v=KUruB156-h4 

\

oAuth2 : Authorization Code Grant Flow

 

• OAuth2 is an authorization framework 
• There are different authorization flows , depending on the app type (SPA , Server side, mobile, TV, smart devices etc) 

OAuth2 = Open Authorization 2.0 (delegated authorization framework)

https://www.youtube.com/watch?v=7D-OU4hZW70

NOTE : App uses a short lived Authz Code to get a longer lived Access token

once the resource-server gets the 'access token' from app it gets & compares it to access token from authorization-server

there are 5 roles in the above flow

1.1. Request To Authorization Endpoint

GET {Authorization Endpoint}

  ?response_type=code             // - Required

  &client_id={Client ID}          // - Required

  &redirect_uri={Redirect URI}    // - Conditionally required

  &scope={Scopes}                 // - Optional

  &state={Arbitrary String}       // - Recommended

  &code_challenge={Challenge}     // - Optional

  &code_challenge_method={Method} // - Optional

  HTTP/1.1

HOST: {Authorization Server}

1.2. Response From Authorization Endpoint

HTTP/1.1 302 Found

Location: {Redirect URI}

  ?code={Authorization Code}  // - Always included

  &state={Arbitrary String}   // - Included if the authorization

                              //   request included 'state'.

1.3. Request To Token Endpoint

POST {Token Endpoint} HTTP/1.1

Host: {Authorization Server}

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code  // - Required

&code={Authorization Code}     // - Required

&redirect_uri={Redirect URI}   // - Required if the authorization

                               //   request included 'redirect_uri'.

&code_verifier={Verifier}      // - Required if the authorization

                               //   request included

                               //   'code_challenge'.

If the client type of the client application is “public”, the client_id request parameter is additionally required. On the other hand, if the client type is “confidential”, depending on the client authentication method, an Authorization HTTP header, a pair of client_id & client_secret parameters, or some other input parameters are required. See “OAuth 2.0 Client Authentication” for details.

1.4. Response From Token Endpoint

HTTP/1.1 200 OK

Content-Type: application/json;charset=UTF-8

Cache-Control: no-store

Pragma: no-cache

{

  "access_token": "{Access Token}",    // - Always included

  "token_type": "{Token Type}",        // - Always included

  "expires_in": {Lifetime In Seconds}, // - Optional

  "refresh_token": "{Refresh Token}",  // - Optional

  "scope": "{Scopes}"                  // - Mandatory if the granted

                                       //   scopes differ from the

                                       //   requested ones.

}