Before OAuth existed, “connecting” one app to another meant something uncomfortable: handing over your password.

Picture an early version of the web where you wanted a photo-printing website to grab your vacation photos from your email account’s file storage. The only way to do that back then was to type your email username and password directly into the photo-printing website. That website now had your full password — the same one you used to read private messages, manage your contacts, and maybe reset your bank login. It could do anything your email account could do, forever, until you manually changed your password everywhere.

This pattern, called password sharing or the “password anti-pattern,” caused three big problems. First, the receiving app got far more access than it actually needed — it wanted to read files, but it could now do everything. Second, there was no way to limit how long that access lasted; the password worked until you changed it. Third, there was no way to revoke access to just one app without changing your password everywhere else, which would log you out of every other connected service too.

OAuth 2.0 — short for “Open Authorization,” version 2.0 — was designed to solve exactly this. Instead of handing over a password, an app receives a limited, temporary, revocable piece of evidence called a token. That token says, in effect, “this app is allowed to read your photos, and only your photos, until next Tuesday.” The password itself never leaves the service that owns it. This single shift — from sharing a password to sharing a scoped, expiring token — is the entire foundation of everything else in this tutorial.

It’s worth appreciating how much the web changed once this problem became common enough to need solving. In the early 2010s, the number of apps trying to connect to each other exploded — photo printers wanted access to cloud photo albums, budgeting apps wanted read-only access to bank transactions, scheduling tools wanted to peek at calendars, and social apps wanted to find contacts who were already using the service. Password sharing simply could not scale to that world safely. A standard was needed that every company could implement independently, yet that would still work consistently when apps from different companies needed to talk to each other. That standard is what a group of engineers and companies published in 2012 as OAuth 2.0, and it has been the backbone of cross-application access ever since.

OAuth always involves the same four roles, no matter which website or app you’re using. Learning their names makes every diagram later in this tutorial easy to read.

There is a fifth term worth learning early: scope. A scope is a specific, named permission — like read:photos or read:calendar — that describes exactly what a token allows. Scopes are how “limited access” becomes something a computer can check mechanically, rather than a vague promise. When you see a consent screen listing bullet points like “view your email address” and “view your basic profile info,” each bullet is a scope the app is requesting.

More confusion about OAuth comes from what people assume it does than from what it actually does. This chapter clears up the biggest myths before we go further.

Keeping these distinctions straight early will make the rest of this tutorial — and any real OAuth implementation you touch — far less confusing.

If scopes are the permissions, tokens are the physical proof of those permissions. There are three kinds worth knowing.

Most access tokens today are formatted as a JWT, short for JSON Web Token — a compact, signed block of text that a Resource Server can verify without even calling the Authorization Server, because the signature itself proves it was issued legitimately and hasn’t been tampered with. Some systems instead use “opaque” tokens, which look like random strings and require the Resource Server to check with the Authorization Server every time. Both approaches are valid; JWTs trade a network call for a slightly bigger token, while opaque tokens trade a bigger token for an extra check.

It helps to understand what a JWT-formatted access token actually contains, without needing to look at any code. Conceptually, it’s made of three parts glued together: a small header describing how it was signed, a payload of claims — facts like who issued it, which client it was issued to, which scopes it covers, and when it expires — and a signature that mathematically ties the header and payload together so that changing even one character invisibly breaks the signature. A Resource Server can check that signature using a public key published by the Authorization Server, which is why it can trust the token without having to phone home for every single request.

A “grant type” is simply the specific recipe of messages used to get a token. OAuth defines several, because a mobile app, a server, and a smart TV can’t all be trusted in the same way.

PKCE (pronounced “pixy,” short for Proof Key for Code Exchange) deserves a special mention because it has become the default safeguard for the Authorization Code flow, even for confidential server-side clients. Before starting the flow, the client generates a random secret and sends only a scrambled version of it upfront. Later, when exchanging the authorization code for tokens, it must reveal the original secret. This proves that whoever is redeeming the code is the same party who started the flow — closing a gap where a malicious app on the same device could otherwise intercept the code and steal it.

Zooming out from individual flows, here’s how the four roles typically sit relative to each other in a real system.

flowchart LR
    U["Resource Owner
(the user)"] -- logs in & approves --> AS["Authorization Server
(issues tokens)"]
    C["Client
(the app)"] -- 1: redirects user to --> AS
    AS -- 2: returns authorization code --> C
    C -- 3: exchanges code for tokens --> AS
    C -- 4: sends access token with API calls --> RS["Resource Server
(holds the data)"]
    RS -- 5: validates token, returns data --> C
        

Notice that the Client never talks directly to the Resource Server to get permission — permission always comes from the Authorization Server first. The Resource Server’s only job regarding OAuth is to check that an incoming access token is valid and covers the right scope, then serve or refuse the request accordingly. This separation is intentional: it means the same Authorization Server can protect many different Resource Servers (for example, one company’s login system protecting its mail API, its calendar API, and its file-storage API) without each of those APIs needing to know how to check passwords or run a login page.

In practice, the Authorization Server and one or more Resource Servers are often operated by the same company — Google’s login system and Google’s Gmail API both belong to Google — but architecturally they remain separate responsibilities, and large companies frequently run them as genuinely separate internal systems for exactly this reason.

This is the flow behind most “Sign in with…” and “Connect your account” buttons you’ve ever clicked. Here it is broken into individual steps.

sequenceDiagram
    participant User as Resource Owner
    participant Client as Client App
    participant AS as Authorization Server
    participant RS as Resource Server

    Client->>AS: Redirect user with scopes + PKCE challenge
    AS->>User: Show login and consent screen
    User->>AS: Approve requested scopes
    AS->>Client: Redirect back with one-time authorization code
    Client->>AS: Exchange code + PKCE secret for tokens
    AS->>Client: Return access token and refresh token
    Client->>RS: API request with access token
    RS->>Client: Return requested data
        

Two design choices here are easy to overlook but do most of the security work. First, the authorization code is exchanged for tokens through a direct, private request — not through the browser’s visible address bar — so nothing valuable is exposed to whoever might be watching the user’s screen or browser history. Second, the code is single-use and expires within roughly a minute, so even if someone intercepted it, replaying it later would fail.

Getting a token is only the beginning. What happens over the following hours, days, and months matters just as much.

flowchart TD
    A["Access token issued"] --> B{"Token still valid?"}
    B -- Yes --> C["Used for API calls"]
    C --> B
    B -- Expired --> D{"Refresh token available and valid?"}
    D -- Yes --> E["Client requests new access token silently"]
    E --> A
    D -- No / revoked --> F["User must log in again"]
        

An access token’s life is intentionally short. Once it expires, the client doesn’t need to bother the user again — instead it quietly sends the refresh token back to the Authorization Server and receives a new access token, often without the user noticing anything happened. This is why you can stay “logged in” to an app for weeks even though the underlying access token might only last an hour: the refresh token is doing the renewing behind the scenes.

Revocation is the other half of the lifecycle. A well-built Authorization Server lets a user — or an administrator — revoke a refresh token at any time, from a “connected apps” settings page, for instance. Once revoked, the client can no longer silently renew; the next attempt fails, and the user is sent back to log in and re-approve, if they choose to. This single feature is what makes OAuth dramatically safer than the old password-sharing model from Chapter 1: access can be cut off instantly, for one app only, without touching the user’s actual login credentials.

OAuth’s security doesn’t come from one clever trick — it comes from several smaller protections working together.

For browser-based single-page apps in particular, where there’s no truly “secret” place to hide a client secret, the recommended pattern today is the Authorization Code flow with PKCE and no client secret at all — the app is treated as “public,” and PKCE alone provides the needed protection instead of a secret that could never really stay secret in browser code anyway.

Some higher-security environments go a step further with mechanisms like sender-constrained tokens, where an access token is cryptographically bound to the specific client connection that requested it — often using mutual TLS or a similar proof-of-possession technique. This means that even a fully copied access token becomes useless in someone else’s hands, because the token only works when presented alongside the matching private key or connection. This isn’t needed for most everyday apps, but it shows how far the OAuth ecosystem has extended beyond the base specification for cases like banking and government systems.

Like every widely adopted standard, OAuth 2.0 involves real trade-offs, not just wins.

Teams that run an Authorization Server in production watch a specific set of signals to catch problems early.

Some ways of using OAuth are considered solid engineering practice; others quietly reintroduce the very problems OAuth was built to avoid.

A condensed checklist of habits that separate a well-built OAuth integration from a fragile one.

One more habit worth building is treating consent screens as a design surface, not an afterthought. A vague scope name like “full account access” makes users hesitant and makes it harder for them to reason about what they’re approving, while a clear, specific description — “view the names and dates of your upcoming calendar events” — builds trust and reduces support questions later. Teams that invest a little extra effort in writing clear scope descriptions tend to see fewer users abandoning the connection flow partway through.

OAuth 2.0 is not a theoretical standard — it’s the quiet machinery behind everyday interactions with technology.

No. OAuth 2.0 is a specification — a written set of rules describing how the roles, messages, and tokens should behave. Companies and open-source projects then build actual software (Authorization Servers, client libraries) that follows those rules.

Not necessarily. If your app only ever checks its own users against its own database and never needs to access another service’s data on a user’s behalf, a simpler session-based login can be perfectly reasonable. OAuth earns its complexity when multiple separate systems need to trust and authorize each other.

OAuth 1.0 required every request to be individually cryptographically signed, which was secure but painful to implement correctly. OAuth 2.0 simplified this by relying on encrypted connections (HTTPS) plus bearer tokens instead, trading some of that built-in per-request signing for much simpler adoption — which is a big reason it became so widely used.

Individual access tokens still expire on their own short schedule, but yes, as long as the refresh token remains valid and isn’t revoked, a client can keep obtaining new access tokens indefinitely — which is exactly why refresh token revocation and rotation matter so much for real security.

This happens when an app uses OpenID Connect for login and OAuth for API access in the same flow. The ID token answers “who logged in,” while the access token answers “what can this app now do.”

The Authorization Server simply won’t issue a token covering that scope, or may refuse the whole request depending on how the client built it. Well-designed clients handle partial or declined consent gracefully rather than assuming full approval.

The core message flow is standardized, but the specification deliberately leaves some details open — like exactly which scopes exist, how consent screens look, or optional security add-ons a provider chooses to support. This is why connecting to two different providers can feel slightly different even though both are correctly following OAuth 2.0.

Only if those companies have agreed to trust each other’s Authorization Server, which is uncommon outside of specific partnerships or federated identity setups. Normally, a token issued by one company’s Authorization Server is only accepted by that same company’s Resource Servers.

OAuth 2.0 replaced a risky old habit — sharing passwords between services — with something far narrower and safer: scoped, temporary, revocable tokens exchanged between four well-defined roles. It is not an identity system on its own, though OpenID Connect builds one on top of it. Its real-world safety comes not from one clever trick, but from several smaller protections — PKCE, short token lifetimes, scope minimization, redirect validation, and careful token storage — working together. Understood role by role and message by message, what looks like a complicated diagram is really just a small, repeatable pattern used everywhere from “Sign in with Google” buttons to smart TVs and backend services talking to each other.