What Is OAuth? How OAuth 2.0 Works, Explained

OAuth — short for open authorization — is the standard that lets one application access your data on another service without ever seeing your password. The current version, OAuth 2.0, is the protocol behind “Sign in with Google,” “Connect your Spotify,” and nearly every third-party API integration you’ve ever approved. In one sentence: OAuth lets a user grant an app limited, revocable access to their account on another service, using tokens instead of shared credentials.

That last part is the whole point. Before OAuth, connecting two services meant handing app B your app A password and hoping for the best. OAuth replaces that with access tokens: scoped, short-lived, revocable proofs that a user said yes to something specific.

The four roles

OAuth 2.0 defines four participants in every flow:

• Resource owner — the user who owns the data (you, logging into a site).
• Client — the application requesting access (the third-party app).
• Authorization server — the service that authenticates the user and issues tokens (Google, GitHub, your identity provider).
• Resource server — the API holding the user’s data, which the client wants to call.

The authorization server and resource server are often run by the same organization but are logically separate. The client never talks to the resource server until it has a valid token.

How the OAuth flow works, step by step

The most common OAuth 2.0 pattern is the authorization-code flow. Modern implementations add PKCE (Proof Key for Code Exchange, pronounced “pixy”) to close a code-interception attack, and it is now recommended for all clients — including server-side ones.

Here’s what happens when you click “Sign in with Google” on a third-party app:

1. Redirect. The client sends the user’s browser to the authorization server with a client_id, the requested scopes, a redirect_uri, and a PKCE code_challenge (a hashed random value).
2. Consent. The authorization server authenticates the user and shows a consent screen listing what the client is asking for (e.g., “Read your email,” “Access your calendar”). The user approves or denies.
3. Authorization code. On approval, the authorization server redirects back to the client’s redirect_uri with a short-lived authorization code in the URL.
4. Token exchange. The client sends the code to the authorization server’s token endpoint, along with the original PKCE code_verifier. The server validates the hash and, if correct, returns an access token and optionally a refresh token.
5. API calls. The client attaches the access token to requests to the resource server (typically as a Bearer header). The resource server validates the token and returns data.

Notice what never happened: the client never saw the user’s password. Authentication happened entirely on the authorization server’s domain.

Tokens and scopes: what actually gets issued

Access tokens are the credential the client uses to call the API. They are deliberately short-lived — minutes to an hour is typical. An access token may be an opaque random string the resource server looks up, or a signed JWT the resource server can validate locally without a lookup.

Refresh tokens are longer-lived credentials the client can exchange for a fresh access token when the old one expires, without sending the user back through the consent screen. They’re powerful, so they’re only issued to clients that can protect them, and good authorization servers rotate them on every use.

Scopes limit what a token can do. A token scoped to read:profile cannot write to the user’s data even if the resource server supports it. Well-designed clients request the minimum scopes they need — and users should be suspicious of apps that ask for more than their feature set justifies.

The other grant types

The authorization-code flow is the default, but OAuth 2.0 defines several grant types for different situations: client credentials for machine-to-machine calls where no user is involved, the device authorization grant for TVs and CLIs that can’t show a browser, and the refresh token grant for renewing access. Two older flows — implicit and resource owner password — are deprecated and should not be used in new systems. We break down when to use each in our guide to OAuth 2.0 grant types.

OAuth is not authentication

This distinction trips up almost everyone. OAuth is authorization — it answers “is this app allowed to access this resource?” It does not tell the client who the user is. An access token is a capability credential, not an identity credential.

OpenID Connect (OIDC) is the thin layer built on top of OAuth 2.0 that adds authentication. It returns an additional ID token (a signed JWT) containing claims about the user: their name, email, and a stable subject identifier. When you see “Sign in with Google,” OIDC is doing the authentication part; OAuth is doing the authorization part underneath.

If you are building a login system, you want OIDC, not raw OAuth 2.0. Using an access token to verify identity is an anti-pattern. For how OIDC compares with SAML — the older enterprise single-sign-on standard — see OAuth vs OIDC vs SAML.

OAuth 1.0, 2.0, and 2.1

OAuth 1.0 (2007) required every request to be cryptographically signed, which was secure but notoriously painful to implement. OAuth 2.0 (2012) simplified the model to bearer tokens over TLS: whoever holds the token can use it, so the transport must be encrypted — see the HTTPS explainer for how TLS protects the link. Almost everything deployed today is OAuth 2.0 plus a stack of extension RFCs (PKCE among them).

OAuth 2.1 is an in-progress consolidation of that guidance into a single spec: PKCE required everywhere, the implicit and password grants removed, and stricter redirect-URI matching. It doesn’t introduce new mechanics — it makes the current best practices the baseline.

Security best practices

OAuth 2.0 has well-known pitfalls. Follow these to stay safe:

• Always use PKCE. Even for server-side apps — it prevents code interception attacks.
• Keep access tokens short-lived. Minutes to an hour is typical. Use refresh tokens to extend sessions without re-prompting the user.
• Use exact redirect-URI matching. Loose matching is the root of many token-theft bugs.
• Validate scopes. Request the minimum set of scopes your app actually needs.
• Don’t roll your own. Use a well-tested library or hosted identity provider rather than implementing the flow manually.

OAuth dovetails closely with related authentication work. Passkeys are increasingly used to authenticate users at the authorization server, replacing passwords in the consent flow, and delegated authorization is a core building block of zero-trust architectures. Meanwhile, the resources OAuth protects are usually REST APIs exchanging JSON payloads.

Common questions

Is OAuth authentication or authorization?

Authorization. OAuth grants an app permission to access resources; it doesn’t verify identity. Authentication is layered on top by OpenID Connect, which most “Sign in with…” buttons actually use.

What does an OAuth token look like?

Either an opaque string (ya29.a0AfH6...) that only the issuing server can interpret, or a signed JWT whose claims any service can validate with the issuer’s public key. Both are bearer tokens: possession is authority, which is why they’re kept short-lived and sent only over HTTPS.

What’s the difference between OAuth and SAML?

SAML is an older, XML-based standard focused on enterprise single sign-on between an identity provider and applications. OAuth is a JSON/HTTP-era framework focused on delegated API access, with OIDC adding login on top. New consumer-facing systems almost always choose OAuth + OIDC.

Is OAuth safe?

The protocol is sound when implemented to current guidance: authorization-code flow with PKCE, short-lived tokens, exact redirect matching, HTTPS everywhere. Most real-world OAuth breaches come from implementation shortcuts, not the protocol itself.

The takeaway

OAuth 2.0 solves a real problem: letting users grant limited, revocable access to their data without handing over their password. The authorization-code flow with PKCE is the safe default, scopes keep tokens narrow, and refresh tokens keep sessions alive without re-consent. Add OpenID Connect when you need to know who the user is, not just whether they authorized something. Use an existing library, keep tokens short-lived, and always use HTTPS.