The Definitive Guide to OAuth 2.0
The Definitive Guide to OAuth 2.0
If you have ever clicked "Sign in with Google" or "Log in with Facebook", you have used OAuth 2.0. It is the 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.
What is OAuth 2.0?
OAuth (Open Authorization) is an authorization protocol; it deals with permissions.
Imagine you are staying at a hotel. You go to the front desk (Authorization Server) and check in. They give you a key card (Access Token). This card grants you access to your room (Resource) and the gym, but not the manager's office.
- You don't own the hotel.
- You don't get the master key.
- You get delegated access for a limited time.
OAuth 2.0 vs. OpenID Connect (OIDC)
This is the most common confusion point for developers.
- OAuth 2.0 is for Authorization (Accessing resources).
- OpenID Connect (OIDC) is for Authentication (Identifying the user).
OIDC sits on top of OAuth 2.0. When you use OIDC, you get an ID Token (who the user is) alongside the Access Token (what the app can do).
Common Grant Types
The "Grant Type" is simply the method an application uses to get an Access Token.
1. Authorization Code Flow (The Standard)
Used by standard web apps (server-side).
- User clicks "Login".
- Redirected to Auth Server.
- User approves access.
- Auth Server redirects back with a Code.
- App exchanges Code + Client Secret for an Access Token.
2. Proof Key for Code Exchange (PKCE)
Used by mobile and Single Page Apps (SPA) that cannot store a Client Secret securely. It adds a secret "Verifier" and "Challenge" to the Authorization Code Flow to prevent code interception attacks.
- Recommendation: Use PKCE for all applications (web and mobile) today.
3. Client Credentials Flow
Used for machine-to-machine communication (e.g., a backend service talking to a cron job). No user is involved.
Security Best Practices
| Vulnerability | Description | Best Practice Mitigation |
|---|---|---|
| CSRF Attacks | Attacker tricks user into approving a request they didn't intend. | Use a random state parameter in the authorization request and verify it upon return. |
| Code Interception | Malicious app steals the authorization code during the redirect. | Enforce PKCE (Proof Key for Code Exchange). It ensures only the app that initiated the request can exchange the code. |
| Open Redirects | Attacker redirects user to a phishing site after authorization. | Use Exact Match validation for redirect_uri. Never use partial string matching or wildcards. |
| Token Theft (XSS) | Malicious scripts reading tokens from localStorage. | Store tokens in httpOnly, Secure cookies. Do not store sensitive tokens in localStorage. |
OAuth vs. JWT Authentication
How do they fit together?
| Feature | JWT Auth | OAuth 2.0 |
|---|---|---|
| Primary Goal | Stateless Authentication | Delegated Access / Authorization |
| Use Case | Logging into your own app. | Allowing 3rd party apps to access your data. |
| Format | JSON Web Token | Opaque String or JWT |
OAuth 2.0 often uses JWTs as the format for Access Tokens, but the protocol itself defines how to get that token.
Further Reading
To learn more about the underlying technology of tokens, check out our guide on Master JWT Authentication.