OAuth 2.0
An open standard for access delegation, commonly used as a way for users to grant applications access to their information on other websites without giving them their password.
Detailed Explanation
OAuth 2.0 is the protocol behind 'Sign in with Google/GitHub'. It uses 'Access Tokens' to give a third-party application permission to do things on your behalf (like read your profile). It separates the roles of the user, the application (client), and the resource server, making it a secure and flexible choice for modern identity management.
Quick Summary
OAuth 2.0 is a delegation protocol: it lets users grant apps scoped access to their data on another service without sharing their password. It's about authorization, not authentication, OIDC adds the identity layer on top.
Key Takeaways
- Four roles: resource owner (user), client (app), authorization server (issuer), resource server (API).
- Use the Authorization Code flow with PKCE for web and mobile clients, it's the modern default for everything except machine-to-machine.
- Implicit flow is deprecated; password grant is a smell unless you control both ends and have no alternative.
- Tokens have scopes, never request more than the app actually needs.
- OAuth alone proves "this app has permission," not "this user is X." If you need identity, use OIDC.
When to use it
- "Sign in with Google/GitHub/Apple" buttons on third-party apps.
- Allowing a calendar app to read events from a user's Google Calendar without seeing their password.
- Issuing scoped API tokens for first-party mobile apps with PKCE.
- Machine-to-machine API access via the Client Credentials flow.
Common Mistakes
- Using OAuth for authentication instead of OIDC, there's no standard way to identify the user from an access token alone.
- Skipping PKCE on public clients (mobile, SPA), leaves the authorization code interceptable.
- Storing access tokens in localStorage where XSS can grab them; prefer httpOnly cookies or in-memory storage.
- Requesting overly broad scopes "just in case", users see them on the consent screen and bounce.
OAuth 2.0, Frequently Asked
OAuth vs. OIDC, which do I need?
If you need to *call an API on the user's behalf*, you need OAuth. If you also need to know *who the user is* (login), you need OIDC. Most "sign in with X" buttons are doing OIDC, which is OAuth plus an ID token.
Should I build my own OAuth server?
Almost never. Use Auth0, Clerk, Keycloak, Okta, or a framework-provided library. The spec has many subtle security pitfalls (token substitution, state CSRF, redirect URI matching) that mature implementations have already solved.