OAuth 2 Explained In Simple Terms 

That's right! Excellent explanation

This is very true, but if you try to draw arrows for all the redirects and HTTP requests, OAuth flow diagrams tend to become really convoluted.

Whats the difference between oauth 1.0 and oauth 2.0

There is also the server-sided flow that doesn't require a browser redirect though, where the providers can coordinate directly.

2:21 rather than 2:10? I came to the comments to point out the same thing

I noticed this too. Great video overall though!

Yes your correct, but green rectangle. Thanks for pointing that out.

curious to know this too

an authorization code is a temporary credential that serves as proof of the user's consent to access their protected resources. It plays a crucial role in the OAuth flow and is used to obtain an access token, which is then used to make authenticated API requests on behalf of the user. The authorization code flow adds an extra layer of security to the OAuth process. Instead of directly exchanging user credentials (e.g., username and password) for an access token, the authorization code flow separates the authorization and token exchange steps. This way, the access token is not exposed to the client application, reducing the risk of unauthorized access or token leakage. OAuth: Authorization Code Importance In OAuth, an authorization code is a temporary credential that serves as proof of the user's consent to access their protected resources. It plays a crucial role in the OAuth flow and is used to obtain an access token, which is then used to make authenticated API requests on behalf of the user. Here's an overview of why an authorization code is needed in OAuth: User Consent: OAuth is designed to protect user data and privacy. Before an application can access a user's protected resources (such as their profile or data), the user must explicitly grant consent. The authorization code serves as evidence that the user has granted permission for the application to access their resources. Security: The authorization code flow adds an extra layer of security to the OAuth process. Instead of directly exchanging user credentials (e.g., username and password) for an access token, the authorization code flow separates the authorization and token exchange steps. This way, the access token is not exposed to the client application, reducing the risk of unauthorized access or token leakage. Limited Lifetime: Authorization codes have a limited lifetime, typically short-lived, making them less susceptible to misuse. Once an authorization code is issued, it has a short validity period, usually a few minutes. This helps mitigate security risks and reduces the window of opportunity for attackers to intercept and abuse the code. Authorization Code Exchange: After obtaining the authorization code, the client application sends it to the authorization server, along with its client credentials, to exchange it for an access token. This token can then be used to make authenticated API requests on behalf of the user. By using an authorization code, OAuth ensures that the user's consent is obtained, enhances security by separating authorization and token exchange steps, and provides a limited and controlled means of obtaining access tokens. In Authorisation code flow this happens. There are various authentication / authorisation flow available. In the above video authorisation code flow is explained. In which authorisation code is returned after successful authentication. Then authorisation code + client id + secret key is sent to the server which validates that the user is the same as authorization key is the same and it is not tempered. And then the server returns 3 tokens. (1.Access tokens which contain scopes/ permission used for sending requests to get resources. 2.Id token which contain user information/ claims. 3. Refresh token - this is optional.)

​@@avidtechie9734from my perspective as user who will access the resource, the auth code simply like 2FA codes eh? Given from the auth server to the user, then user itself "approve" the permission that the resource should be consumed by the client app right? So then after the user "give the code" to the client app, the client app then can have the access token. Am I right? Or i'm missing something?

Mainly two security benefits: 1. we can avoid sending the access token, which is sensitive information, in the front channel and send it in the back channel instead. 2. we can authenticate the client as well by requiring the client to send client_id and client_secret (along with authorization code) to request the access token. Here's a video that directly answers your question: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-996OiexHze0.html And here's a good illustration of the whole flow: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-PfvSD6MmEmQ.html

This prevents the client from knowing the token. The services may not trust the client or want to charge money for operations without the risk of spoofing.

3:59 also

that's the whole point u need a server to manage access keys

This is actually called federated login. You have a single point of authentication that is trusted and well secured to access all your resources. It wouldn't make much sense to implement an authentication/authorization server into every app, otherwise we would need to trust all apps and single sign-on flows wouldn't be possible anymore. This kind of authentication/authorization also allows zero-trust networks to exist.

Most probably Adobe after effects

it's in the video descriptions

Printmagic has to use its own client ID and secret to authenticate itself to snapstore before it gets the real access token. It's an additional layer of security

@@runilmotwani9549 Thank you

After a long convo with ChatGPT, that's what I came with: There's always some UI involved, as the user needs to consent permissions. As UI's are less secure environments, it'd be risky to give them the access token. That's why we often do the "authorization code access token" exchange in a server environment. Still, would love extra thoughts on this.

Yes, the end user (i.e client).