🔑 OAuth

App: "I need to read your Google calendar"
You: "Here's my Google password"

Problems:
✗ App can end up with broad access to your account
✗ App can send emails as you
✗ App can delete your files
✗ You can't revoke access without changing password
✗ App might store your password insecurely

App: "I need to read your Google calendar"
You: "Let me authorize that through Google..."

[Google asks: Allow this app to view your calendar?]
You: [Yes, allow]

Result:
✓ App can view your calendar (within the scope you approved)
✓ The app doesn't need to see your password
✓ You can revoke access anytime
✓ Access can expire automatically

Resource Owner:  You (the human)
Client:          The app requesting access
Authorization Server:  Google, Facebook, etc. (issues tokens)
Resource Server: Where your data lives (Google Calendar, etc.)

1. YOU want to use an app that needs your calendar

2. APP redirects you to GOOGLE
   "User wants to connect their calendar"

3. GOOGLE asks YOU
   "Allow this app to view your calendar?"
   [Authorize] [Deny]

4. YOU click Authorize

5. GOOGLE redirects back to APP
   With an "authorization code"

6. APP exchanges code for tokens
   (Happens in the background)

7. APP uses tokens to access your calendar
  Your password wasn't shared with the app

┌──────┐     ┌─────────┐     ┌──────────────┐
│ User │────→│   App   │────→│   Google     │
│      │     │(Client) │     │(Auth Server) │
└──────┘     └─────────┘     └──────────────┘
    │             │                  │
    │   1. Click "Connect Calendar"  │
    │─────────────→│                 │
    │              │  2. Redirect    │
    │              │────────────────→│
    │              │                 │
    │ 3. "Allow access?"             │
    │←───────────────────────────────│
    │              │                 │
    │ 4. User approves               │
    │────────────────────────────────→
    │              │                 │
    │              │ 5. Auth code    │
    │              │←────────────────│
    │              │                 │
    │              │ 6. Exchange for token
    │              │────────────────→│
    │              │                 │
    │              │ 7. Access token │
    │              │←────────────────│

What: Short-lived key to access resources
Lifetime: Typically short-lived (varies by provider)
Use: Attached to every API request

Example header: Authorization: <access_token>

In practice, there's usually an auth-scheme prefix (so it looks like: `Authorization: <scheme> <access_token>`).

Many OAuth 2.0 APIs use the standardized scheme defined for access tokens (RFC 6750), but some providers use variations.

Note: OAuth doesn't require a specific token format. Access tokens might be opaque strings or structured tokens (like JWTs), depending on the provider.

What: Long-lived token to get new access tokens
Lifetime: Often longer-lived than access tokens (varies by provider)
Use: Exchange for fresh access token when it expires

Typically not sent to the resource server

1. User authorizes (and may sign in) → Get an access token (and sometimes a refresh token)
2. Make API calls with access token
3. Access token expires
4. Use refresh token to get new access token
5. Repeat until refresh token expires → User logs in again

Scope defines WHAT the app can do:

Full access:
  scope=calendar.full drive.full mail.full
  (Too much! Dangerous!)

Limited access:
  scope=calendar.read

When you authorize, you see:
  "This app wants to:
   ✓ View your calendar events
   ✗ Send emails on your behalf"

For: Web apps (and also SPAs/mobile apps when used with PKCE)
Flow: User → App → Auth Server → App gets code → Exchange for tokens
Often preferred: For server-side apps, tokens can be exchanged/stored on the server

For: Machine-to-machine (no user involved)
Flow: App authenticates directly with ID + secret
Use: Backend services talking to each other

For: Historically used for browser-based apps
Problem: Access credentials can end up in the browser address bar
Status: Generally avoid. Prefer Authorization Code + PKCE instead

For: Mobile and single-page apps
Problem: Can't safely store client secrets
Solution: Dynamic one-time keys
Now: Commonly recommended for public clients

OAuth:
  "Allow this app to access my photos"
  Authorization (what can you do?)

OpenID Connect (OIDC):
  "Use Google to sign me in"
  Authentication (who are you?) + Authorization
OIDC = OAuth + Identity layer

"Continue with Google"
"Continue with Facebook"
"Continue with GitHub"

App doesn't manage passwords.
Users don't create another account.

Note: This is usually implemented with OpenID Connect (OIDC) on top of OAuth.

Slack connecting to Google Drive
Zapier connecting to hundreds of apps
Mobile apps accessing cloud services

Developer builds app using Twitter API
Gets OAuth tokens through developer portal
App tweets on behalf of users who authorize

Avoid implicit flow (credentials can end up in logs, history)

In general: avoid open redirects, require exact matches, and prefer HTTPS redirect URIs.

Mobile and SPA apps can't keep secrets
PKCE adds dynamic verification

If token leaked, damage is limited
Use refresh tokens for long sessions

---

## Common Mistakes

### 1. Storing Tokens Insecurely

```text
If an attacker can run JavaScript in your page (XSS), they can often steal tokens stored in web-accessible browser storage.

Common approaches:
- Store tokens in memory (reduces persistence but still vulnerable to XSS)
- Use httpOnly cookies (reduces token exfiltration via JS, but requires CSRF defenses like SameSite and anti-CSRF tokens)

There's no one-size-fits-all answer — follow your framework/provider guidance and threat model.

State parameter prevents CSRF attacks
Generate a new state value per request, and validate it on return

If you're using OpenID Connect for login, also validate the `nonce` in the ID token.