OAuth2 Demystified
Finally understand what happens when you click "Login with Gmail"
The Password Sharing Problem
Why OAuth2 exists and what problem it solves.
Imagine this scenario...
You want to use a cool new app called PhotoPrinter that can print your Google Photos. Before OAuth, here's what would happen:
PhotoPrinter asks for your Gmail username and password
You type in your actual Google credentials into their website
PhotoPrinter stores your password and uses it to log into Google as you
🚨 Problem 1
PhotoPrinter has your actual password - they could read your emails!
🚨 Problem 2
If PhotoPrinter gets hacked, attackers get your Google password
🚨 Problem 3
You can't revoke access without changing your password everywhere
🚨 Problem 4
PhotoPrinter has full access, not just photos - they could delete everything
Enter OAuth2: The Valet Key
OAuth2 is like a valet key for your car. A valet key:
✓ Can start the car and drive it
✓ Can't open the trunk or glove box
✓ Can be deactivated without changing your main key
✓ Only works for a limited time
With OAuth2, instead of giving PhotoPrinter your password:
PhotoPrinter sends you to Google to log in
Google asks: "Allow PhotoPrinter to view your photos?"
You click "Allow" → Google gives PhotoPrinter a limited token
PhotoPrinter uses the token - they can only see photos, nothing else
Key Insight
You never give your password to the app. You only log in to Google (or whatever service owns your data), and Google issues a limited-access token to the app. The app never sees your credentials.
What You'll Learn
The Players
Who's involved in an OAuth2 flow
Authorization Code Flow
The most common OAuth2 pattern
PKCE
Extra security for mobile & browser apps
Tokens
Access tokens, refresh tokens, JWTs
OpenID Connect
Adding identity to OAuth2
Security Pitfalls
Common mistakes and how to avoid them