Authentication vs Authorization
Every time you click "Sign in with Google" or "Login with GitHub", you're using OAuth. But what exactly is happening behind that button?
AUTHENTICATION (AuthN)
Who are you?
- Verifying identity
- Username + password
- Biometrics, MFA
- Proves you are who you claim to be
AUTHORIZATION (AuthZ)
What can you do?
- Granting permissions
- Access control
- Scopes and roles
- Determines allowed actions
The Problem OAuth Solves
Imagine you want to use a third-party app to manage your GitHub repositories. Before OAuth, you'd have to give that app your GitHub password.
- App has full access to your account
- Can't revoke access without changing password
- If app is compromised, your password is exposed
- Can't give different apps different permissions
- App gets a token, not your password
- Tokens can be revoked individually
- Limited scopes (read-only, specific resources)
- Tokens can expire automatically
The Hotel Key Card Analogy
Think of OAuth like a hotel key card:
Master key to everything
Room-specific key card
Deactivates at checkout
Only opens your room
OAuth Roles
OAuth defines four key roles in every authorization flow:
| Role | Description | Example |
|---|---|---|
| Resource Owner | The user who owns the data | You (the GitHub user) |
| Client | App requesting access | A CI/CD tool like CircleCI |
| Authorization Server | Issues tokens after auth | GitHub's OAuth server |
| Resource Server | Hosts the protected resources | GitHub's API |
Real-World: "Sign in with Google"
When you click "Sign in with Google" on a website:
1. Website redirects you to Google
2. Google asks: "Allow this app to access your email and profile?"
3. You click "Allow"
4. Google sends a token back to the website
5. Website uses token to get your info from Google
6. Website creates your account (never sees your Google password)The third-party website never sees your Google password. They only get a limited-access token that you can revoke at any time from your Google account settings.
OAuth 2.0 vs OAuth 1.0
OAuth 2.0 is the current standard. It replaced OAuth 1.0 with:
OAuth 2.0 Improvements
- Simpler implementation
- Better support for mobile apps
- Multiple flow types for different use cases
- Short-lived access tokens + refresh tokens
OAuth 1.0 Issues
- Complex cryptographic signatures
- Hard to implement correctly
- Poor mobile support
- Single token type
Key Takeaways
- Authentication = WHO - Verifying identity
- Authorization = WHAT - Granting permissions
- OAuth enables delegated access - Apps get tokens, not passwords
- Tokens are like hotel key cards - Limited, revocable, expirable
Next up: OAuth 2.0 Flows - The different ways applications can get access tokens.