OAuth 2.0
What it is
OAuth 2.0 (RFC 6749) is the authorization framework behind "Sign in with..." and "Connect your account" buttons. It lets a user grant an application limited, scoped access to their resources at another service without sharing a password. Crucially, OAuth is about authorization, not authentication: it answers "what may this app do," not "who is this user." Using an access token as proof of login is the classic OAuth mistake, which is what OpenID Connect exists to fix.
How it works
The core actors are the resource owner (user), the client (app), the authorization server, and the resource server (API). The client redirects the user to the authorization server, the user consents, and the client receives an access token (and often a refresh token) it presents to the API.
- Access token: a short-lived credential scoped to specific permissions.
- Refresh token: exchanged for new access tokens without re-prompting the user.
- Scopes: the permissions being requested, such as
read:calendar. - Grants (flows): the authorization code flow with PKCE for user-facing apps, and the client credentials grant for machine-to-machine.
Status
RFC 6749 dates to 2012 and is universally deployed. The IETF published the OAuth 2.0 Security Best Current Practice as RFC 9700 in 2025, and OAuth 2.1 consolidates that guidance into one specification.
Pitfalls
- Treating an access token as authentication. Use OpenID Connect for login.
- The implicit and resource-owner-password grants are discouraged; do not use them in new builds.
- Always use PKCE, validate redirect URIs strictly, and keep tokens short-lived.
Related
Glossary: OAuth, scopes and claims, token exchange. Guide: OAuth vs OIDC and the implementation guide.