RFC 8693 OAuth 2.0 Token Exchange

 https://www.rfc-editor.org/rfc/rfc8693

How an empty S3 bucket can make your aws bill explode

 https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1

So, if I were to open my terminal now and type:

aws s3 cp ./file.txt s3://your-bucket-name/random_key

I would receive an AccessDenied error, but I would be the one to pay for that request. And I don’t even need an AWS account to do so.

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://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.

}