OAuth

A short, practical guide to OAuth 2.0. What it does, what it doesn't do, how OpenID Connect fits on top.

Articles

OAuth is one of those standards that almost everyone has used without quite knowing what it is. Every time you click “Allow this app to access your Google account”, you’re driving an OAuth flow. The name gets borrowed for all sorts of things it isn’t, so it’s worth setting out what OAuth actually does, what it doesn’t, and how the related standards (OpenID Connect, SAML) fit around it.

This matters more, not less, as AI agents take on real work. When an agent books a meeting, queries a CRM, or drafts an email on a user’s behalf, it’s hitting exactly the problem OAuth was designed for: how do you grant scoped, revocable, auditable access to another party without handing over the keys? Getting these fundamentals right is the foundation for doing agentic work safely.

What OAuth is for

OAuth 2.0 is a standard for delegated authorisation. It lets a user grant one application limited access to their data or actions in another application, without handing over their password.

The classic example: a scheduling app wants to read your Google Calendar. You don’t want to give the scheduling app your Google password. OAuth lets Google issue the scheduling app a scoped access token that says “this app can read this user’s calendar, for the next hour, and nothing else.”

Key things to notice:

  • The user is not logging into the scheduling app with OAuth. OAuth isn’t primarily an authentication protocol.
  • The access is scoped. The token grants specific permissions, not blanket access.
  • The access is revocable. The user can pull permissions back at any time without changing their password.

The four parties

OAuth flows involve four roles:

  1. Resource Owner: the user who owns the data.
  2. Client: the application that wants access (the scheduling app).
  3. Authorisation Server: the system that issues tokens (Google’s OAuth server).
  4. Resource Server: the API holding the data (Google Calendar’s API).

The Authorisation Server and Resource Server are often run by the same company, but they’re logically separate.

How it works

The most common flow is the Authorisation Code flow:

  1. The Client sends the user to the Authorisation Server with a request: “I want these scopes (calendar.read), here’s who I am, send the user back to this URL when done.”
  2. The user logs in to the Authorisation Server (if they aren’t already) and sees a consent screen: “SchedulingApp wants to read your calendar. Allow?”
  3. If the user agrees, the Authorisation Server redirects the user back to the Client with a short-lived authorisation code.
  4. The Client takes that code and, server-to-server, exchanges it with the Authorisation Server for an access token (and usually a refresh token).
  5. The Client calls the Resource Server’s API, including the access token in the request header. The Resource Server validates the token and returns the data.

Access tokens are short-lived (often minutes to an hour). Refresh tokens are longer-lived and let the Client get a new access token without prompting the user again.

Modern OAuth clients use PKCE (Proof Key for Code Exchange) on top of this flow. It’s an extra cryptographic check that helps prevent an attacker from intercepting the authorisation code. PKCE started out as a mobile protection, but it’s now recommended for most client types.

Access tokens

Access tokens come in two broad shapes. Some are opaque strings that the Resource Server validates by calling back to the Authorisation Server. Others are JWTs (JSON Web Tokens): self-contained, signed tokens that carry claims such as the user ID, the scopes granted, and an expiry time, which the Resource Server can validate locally by checking the signature.

JWTs are popular because they’re stateless and fast to validate at scale. The trade-off is that revocation is harder, since a JWT tends to remain technically valid until it expires.

OpenID Connect and login

Here’s where people get confused. OAuth isn’t really designed for “log in with Google” in a strict sense. It grants access to APIs, not proof of identity. Applications wanted a way to use OAuth for login anyway, so the OpenID Connect (OIDC) standard was built on top.

OIDC adds one thing: an ID token, which is a signed JWT containing verified information about the user (their ID, email, name, when they logged in). The ID token is meant for the Client to consume. The access token, in contrast, is meant for calling APIs.

So when you click “Log in with Google” on a modern site, you’re typically using OIDC. The site asks for the openid scope, gets back an ID token, verifies its signature, and logs you in on the basis of its claims.

OIDC is widely adopted for new identity work on the web. It’s compact, mobile-friendly, JSON-based, and well supported by every major identity provider.

Where SAML fits

SAML solves a similar problem to OIDC, but predates it by about a decade. It’s XML-based, more verbose, and still dominant in enterprise single sign-on. If you’re integrating with a corporate IT department, SAML is often the default, although OIDC is catching up.

The short version: SAML for enterprise SSO today, OIDC for most new integrations, OAuth for API access. For a fuller treatment of SAML, see SAML vs OAuth: What SAML Actually Does.

Common OAuth flows

OAuth defines several flows for different client types:

  • Authorisation Code (with PKCE): the standard flow for web and mobile apps. Use this by default.
  • Client Credentials: for machine-to-machine access where there’s no user involved. The Client authenticates with its own credentials and gets a token.
  • Device Code: for devices that can’t easily show a browser (smart TVs, CLIs). The user completes the flow on a separate device.
  • Implicit and Resource Owner Password: legacy flows, now discouraged. Don’t use them in new work.

When to use OAuth

Rough guide:

  • Third-party app needs limited access to user data in another system? OAuth.
  • Building “Log in with Google/Microsoft/Apple”? OIDC (which runs on OAuth).
  • Federating enterprise employee identity across internal SaaS? SAML, or increasingly OIDC.
  • Letting an AI agent act on a user’s behalf against an API? OAuth, with tight scopes and short-lived tokens.

A common architecture: OIDC handles user login, OAuth handles any delegated API access after that, and SAML sits in the enterprise SSO layer when selling into larger customers. Agent access slots into the OAuth layer, which is why scope design is becoming a governance question, not just an engineering one.

Conclusion

OAuth is about authorisation, not authentication. It lets applications, and increasingly agents, act on a user’s behalf with scoped, revocable tokens, without touching the user’s password. OpenID Connect bolts a standard identity layer on top, and that’s what most modern login flows actually use. SAML still rules enterprise SSO, though the weight of new work is shifting towards OIDC.

If you remember one thing: an access token is for calling APIs, an ID token is for knowing who the user is. Keep the two straight and most OAuth confusion goes away.