What Is OAuth 2.0?

Quick answer
OAuth 2.0 is a standard for delegated authorization: an app gets limited access to your data on another service without your password.
It issues tokens that represent specific, scoped permissions, which can be revoked without changing your password.
The most common flow is the authorization code flow, used by web apps and mobile apps alike.

What is OAuth 2.0?

OAuth 2.0 is an open authorization framework (RFC 6749) that lets one application access resources on another service on a user’s behalf, without the user handing over their password. When you click “Sign in with Google” or authorize an app to read your GitHub repos, OAuth is what makes that possible: the service issues the app a token with limited, revocable permissions.

Core concepts

Resource owner: the user whose data is being accessed.
Client: the application requesting access.
Authorization server: the service that authenticates the user and issues tokens.
Access token: the credential the client presents to access resources.
Scopes: the specific permissions the token carries (“read email,” not “delete everything”).

The authorization code flow

The standard web-app flow works in a few steps: the app redirects the user to the authorization server; the user authenticates and consents to specific scopes; the server returns an authorization code; the app exchanges that code, with its client secret, for an access token; the app uses the token to call the API. The code-for-token exchange keeps the token out of the browser’s hands.

Why it matters

OAuth replaces the anti-pattern of users sharing passwords with third parties. Tokens are scoped, expiring, and revocable, so access can be narrow and temporary. It’s also the foundation beneath OpenID Connect (OIDC), which layers authentication (who you are) on top of OAuth’s authorization (what the app may do).

Where this bites vibecoders
AI assistants are happy to wire up “Sign in with Google” but often gloss over the subtle parts: validating the token, checking scopes, and keeping the client secret out of frontend code. The result is a login that looks right but accepts any token or leaks the secret. OAuth’s security is in the details — the flow is only as safe as the validation you actually implement.

Where AI coding assistants get this wrong

Putting client secrets in browser or mobile code where they’re extractable.
Accepting access tokens without validating signature, audience, issuer, and expiry.
Skipping the state parameter, opening the door to CSRF during login.
Ignoring scopes and assuming a valid token means full access.

Checklist

Use the authorization code flow (with PKCE for public clients).
Keep client secrets server-side only.
Validate every token: signature, audience, issuer, expiry.
Request and check the minimum scopes needed.
Add the state parameter to prevent login CSRF.

FAQ

What is the difference between OAuth and OpenID Connect?

OAuth 2.0 is about authorization — what an app may access. OpenID Connect (OIDC) is a layer on top that adds authentication — proving who you are — and returns an ID token with identity claims. Most “Sign in with X” buttons use OIDC.

What is an access token?

An access token is a short-lived credential the client presents to an API to prove it’s authorized for specific scopes. It’s what replaces the password in OAuth, and it can be revoked independently of the user’s credentials.

Is OAuth more secure than passwords?

For third-party access, yes: it’s scoped, expiring, and revocable, where a shared password is none of those. But OAuth is easy to implement insecurely, so its safety depends on following the flow correctly.