OAuth 2.0 Flow – What, Why & How

OAuth is everywhere — from logging in with Google to giving third-party apps permission to access your data without sharing your password.

Read here

Role	Who/What
Resource Owner	You (the user)
Client	The app requesting access (e.g., Notion, Figma)
Authorization Server	Google/Facebook – verifies you and issues tokens
Resource Server	The API holding the data (e.g., Google Calendar API)

App redirects user to Authorization Server
- GET https://accounts.google.com/o/oauth2/auth?...
- User sees a login screen.
User logs in and approves permission
- Example: “Allow this app to access your contacts?”
Authorization Server redirects back with a short-lived code
- Sent to the client app’s redirect URI.
Client exchanges code for access_token
- Client sends this code (and secret, if applicable) to the auth server.
- Response: access_token + optional refresh_token
Client uses access_token to call APIs
- Example: GET /contacts with Authorization: Bearer access_token
When token expires, refresh using refresh_token
- No need to ask the user again.

Flow	Use Case
Authorization Code	Full login experience (most secure for mobile/web)
Client Credentials	No user, app-to-app auth (e.g., backend services)
Implicit Flow	Deprecated (was used for pure client-side apps)
Device Code Flow	TV or CLI devices without browser input
PKCE (for mobile)	Authorization Code Flow with extra security (for native apps, avoids needing client secret)

If you’re integrating Google Sign-In, GitHub OAuth, Spotify login, etc. — you’re using OAuth under the hood.
Understanding OAuth helps:
- Avoid security mistakes (like leaking tokens)
- Implement proper token storage (don’t store access tokens in plaintext on Android)
- Use PKCE properly in native apps
Helps in SSO (Single Sign-On), federated identity, and secure auth flows

Vignesh's Dumpster 🗑️