OAuth

What is OAuth?

OAuth is the protocol behind every "Sign in with Google" button and every "Allow this app to access your Google Drive" screen. It lets one application get limited access to your account on another service without ever seeing your password.

The official name is OAuth 2.0, defined in RFC 6749. The one line worth memorising: OAuth is delegated authorization, granting an app permission to do specific things on your behalf. When you click Allow, you never hand over your credentials. Instead, a service issues the app a token that works inside the limits you approved, and that you can switch off later.

That is the whole point. A password gives whoever holds it full access to your account. An OAuth token can be scoped to "read your calendar" and nothing else, expires on its own, and can be revoked from an admin screen without you resetting a single password.

Authorization is not authentication: OAuth versus OpenID Connect

This is the single most common mistake people make with OAuth, so it is worth being blunt about it. OAuth answers the question "what is this app allowed to do?" It does not answer "who is this user?" OAuth on its own is an authorization protocol, not a login system.

The authentication layer is a separate standard called OpenID Connect (OIDC), which its own specification describes as a simple identity layer on top of the OAuth 2.0 protocol. OpenID Connect reuses the same flows but adds one thing: an ID token, a signed JWT that tells the app who just logged in and when. So the difference comes down to which token you get back:

• An access token answers "what can this app do?" The client presents it to an API to reach protected data.

• An ID token answers "who is this person?" It carries identity claims such as the user's ID and email, and it is meant for the app, not for an API.

When you see "Sign in with Microsoft" and it actually logs you in, OpenID Connect is doing the identity part and OAuth is doing the access part. Plain OAuth was never designed to prove identity, and treating an access token as proof of who someone is has caused real security holes. If you need single sign-on, you need OpenID Connect, not OAuth by itself.

The four roles in an OAuth exchange

Every OAuth flow has four parties. Keeping them straight makes the rest of the protocol obvious.

• Resource owner. The person or organisation that owns the data, usually you. The specification defines it as an entity capable of granting access to a protected resource.

• Client. The application asking for access, for example a scheduling tool or a data connector.

• Authorization server. The service that authenticates the resource owner, shows the consent screen, and issues tokens. Google, Microsoft Entra ID, and Okta all play this role.

• Resource server. The API that actually holds the data or performs the action, and that checks the access token on every request.

A worked example. You use a scheduling app that needs to read your Google Calendar. You are the resource owner. The scheduling app is the client. Google's login and consent service is the authorization server. The Google Calendar API is the resource server. The app never learns your Google password. It ends up with an access token limited to reading calendar events.

The authorization code flow with PKCE

OAuth defines several flows, which the specification calls grants. For almost anything with a user in front of it, current guidance points to one flow: the authorization code flow with PKCE (Proof Key for Code Exchange, RFC 7636). It is the recommended default for server-side web apps, single-page apps, and native mobile apps alike.

Here is the flow with the calendar example:

1. The client generates a random secret called a code_verifier and sends a hashed version of it, the code_challenge, when it redirects you to the authorization server.

2. You authenticate with Google and see the consent screen listing the exact permissions requested. You click Allow.

3. Google redirects back to the app with a short-lived authorization code, not a token.

4. The client sends that code back to Google together with the original code_verifier. Only the app that started the flow knows it.

5. Google checks the verifier against the earlier challenge and, if they match, returns the access token.

PKCE exists to stop an attacker who intercepts the authorization code from redeeming it, because the attacker will not have the verifier. It was created to protect native apps, which cannot keep a client secret hidden, and the recommendation now covers everyone. The OAuth 2.0 Security Best Current Practice (RFC 9700) says public clients must use PKCE and that authorization servers must support it.

Two older flows are on the way out, and it matters for security. The implicit flow, once used by single-page apps to get a token straight from the redirect, should no longer be used, because the token came back in the browser URL, where it was easy to leak. The resource owner password credentials grant, where the app collects your real username and password and forwards them, must not be used at all: it defeats the entire reason OAuth exists. RFC 9700 calls out both.

Access tokens, refresh tokens, and scopes

Three concepts do most of the work once a flow completes.

Access token. The credential the client sends to the resource server on each API call. Access tokens are deliberately short-lived, often minutes to an hour, so a leaked one stops working quickly.

Refresh token. A longer-lived credential the client can exchange for a fresh access token when the old one expires, without dragging you back through the consent screen. A refresh token is more sensitive precisely because it lasts longer, so it needs careful storage and can be revoked centrally.

Scopes. The list of permissions attached to a token, written as short strings such as calendar.readonly or mail.read. Scopes are your real security boundary. An app that only needs to read orders should request a read-only scope, not full read-write access. This is where the principle of least privilege lives in OAuth: ask for the narrowest scope that does the job.

Client credentials for server-to-server. Not every integration has a human clicking Allow. When one backend service talks to another, for example a nightly job pulling data through an iPaaS connector, there is no resource owner to prompt. The client credentials flow covers this: the client authenticates as itself with its own client ID and secret and receives an access token tied to the application rather than a user. This is the standard pattern for machine-to-machine API access.

What to watch out for with OAuth

Scope creep undoes the benefit. The safety of OAuth comes from narrow scopes. An app that asks for "read and write everything" has thrown that away. Review what a connector actually requests before you approve it, and prefer least privilege over convenience. The same discipline matters when you connect an AI assistant to your systems through an MCP server: its reach is bounded by the OAuth scopes you approve, so grant the narrowest set that works.

Tokens are secrets. An access token is a bearer credential, meaning whoever holds it can use it until it expires. Never log tokens, never put them in a URL, and store refresh tokens the way you would any other secret. This is where secret management and, in front of your APIs, an API gateway earn their place.

Consent has to be readable. A consent screen that says "this app wants full access to your account" is a design failure. Users and admins should see which permissions an app is asking for and why, and admins should be able to revoke that access without resetting passwords.

Use the current flows. If a vendor SDK or an old tutorial still tells you to use the implicit flow or to collect the user's password directly, treat it as out of date. The authorization code flow with PKCE is the answer for interactive apps, and client credentials for backend services. Pairing scoped OAuth access with a zero-trust data architecture, where every request is authorised on its own merits, is the direction current guidance points.