OAuth 2.0 is an open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

Think of a Valet Key for a car:

1. You have a Master Key (Your Password). It can open the trunk, the glovebox, and start the car.
2. You don't want to give the Valet your master key.
3. You give them a Valet Key (The OAuth Token).
4. The Valet Key can only Start the car and Drive it 5 miles. It cannot open the trunk.
5. The Valet (Application) gets the job done without ever seeing your master key.

---

OAuth vs OpenID Connect (OIDC)

• OAuth 2.0: For Authorization. "Let this app post to my Twitter."
• OIDC: For Authentication. "Sign in with Google." (It's a layer on top of OAuth).

The "Four Actors" in OAuth

1. Resource Owner: You (The user).
2. Client: The app you are using (e.g., a photo editor).
3. Authorization Server: The service that asks "Do you allow this?" (e.g., Google).
4. Resource Server: The place where your data lives (e.g., Google Photos).

The Flow (Grant Types)

1. Authorization Code Flow: Most secure. Used for web apps. Involves a temporary code that is swapped for a token.
2. Implicit Flow: Obsolete. Used for JavaScript apps in the old days.
3. Client Credentials: For service-to-service communication (no user involved).

---

Use Case: "Sign in with Google"

Why is this safe? Answer: Because the application never sees your Google password. It only receives a "Token" from Google saying "Yes, this is John, and I've verified him."

Scopes

The "Scopes" are the specific permissions requested (e.g., read:email, write:profile). Always mention that tokens should have the Narrowest Scope possible.

Security: state parameter

In the OAuth redirect, we always send a random string called state. Why? To prevent CSRF (Cross-Site Request Forgery) attacks where an attacker might try to "Inject" their own authorization code into your session. 🔑