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

\