What Is OAuth? Delegated Access Without Passwords

Here's the thing most tutorials get backwards from the first sentence: OAuth doesn't log you in. It was never designed to. OAuth is about delegation — letting one app do a specific job on your behalf inside another service, without that app ever seeing your password. The 'Sign in with Google' button you're probably picturing is a newer identity layer bolted on top. Strip that away and OAuth's actual job is narrower, older, and more useful than 'login': it hands out limited, revocable permission slips.

Once that clicks, the rest of OAuth stops feeling like alphabet soup. So let me take the common myths one at a time and replace each with what OAuth actually does.

The valet-key picture

Some cars come with a valet key. It starts the engine and opens the driver's door, but it won't unlock the trunk or the glovebox, and some limit how far you can drive. You hand it to someone you don't fully trust — a parking attendant — precisely because it grants one narrow capability and nothing more. Your real key stays in your pocket.

That's OAuth. When you let a photo-printing app reach your cloud storage, you don't give it your storage password (your real key). You give it the equivalent of a valet key: permission to read the photos folder, nothing else, revocable the moment you change your mind. Hold that image and every piece of the flow below has an obvious place.

The four parties

OAuth choreographs four roles, and naming them removes most of the confusion:

• Resource owner — you, the person who owns the data.
• Client — the app that wants to act on your behalf (the printing app).
• Authorization server — the service that authenticates you and issues tokens (Google's, GitHub's, etc.).
• Resource server — the API that actually holds your data and accepts the token (the storage API).

The whole point is that the client talks to the authorization server to get a token, and never learns your password in the process. You authenticate directly with the provider you already trust.

Myth 1: "OAuth logs users in"

This is the big one. OAuth answers what is this app allowed to do, not who is this person. Those are different questions. The reason 'Sign in with Google' feels like login is that a thin standard called OpenID Connect (OIDC) sits on top of OAuth and adds an identity token describing who you are. Underneath, it's still OAuth granting delegated access — OIDC just piggybacks a verified identity onto the same handshake. If you only need 'let this app read my calendar,' that's pure OAuth and no login is implied.

Myth 2: "The app gets a password-equivalent"

Watch what the client actually receives. In the common authorization code flow, the client redirects you to the authorization server, you log in there and approve a list of scopes (read:photos, say), and you're redirected back with a short-lived, single-use code. The client then exchanges that code — server to server — for an access token.

That access token is not your password. It's scoped (only the permissions you approved), it expires (often in minutes to an hour), and it can be revoked without you touching your real credentials. It's the valet key, not the master key. Access tokens are usually JSON Web Tokens, which means the token itself carries readable claims — you can drop one into the JWT Decoder to see its scopes and expiry, and check exactly when it expires with the JWT Expiration Checker.

Myth 3: "Once granted, access lasts forever"

Short-lived access tokens would be annoying if you had to re-approve every hour, so OAuth splits the job. Alongside the access token, the authorization server can issue a refresh token: a longer-lived credential the client uses at one endpoint to silently mint fresh access tokens. Short access token caps the damage of a leak; the refresh token restores convenience; and because the server can revoke a refresh token, it's how 'disconnect this app' actually works. It's the same two-token split covered in what is a refresh token.

How the token rides on each request

Once the client has an access token, it sends it on every API call in the Authorization: Bearer <token> header. 'Bearer' means possession equals access — whoever holds the token can use it — which is why OAuth leans so hard on HTTPS, short lifetimes, and scopes. If you're wiring this up, the Bearer Token Parser pulls the token cleanly out of that header, and the deeper mechanics live in what is a bearer token.

OAuth vs an API key

It's worth drawing the line against the simpler credential. An API key — the kind you'd mint with an API Key Generator — identifies an application and typically grants broad, long-lived access with no user consent step. OAuth delegates a specific user's access to an app, with explicit consent, narrow scopes, expiry, and per-grant revocation. Reach for an API key for server-to-server calls you fully control; reach for OAuth when an app needs to act on an end user's behalf against a third-party service.

The one-line version

OAuth is a delegation framework: it lets you grant an app a scoped, expiring, revocable permission slip to your data on another service, without ever handing over your password. It authorizes rather than authenticates (OpenID Connect adds the identity part), it issues bearer tokens that are usually JWTs, and it pairs a short access token with a refresh token so security and convenience both survive. Hand out the valet key, keep the master key in your pocket.

And when you do need the identity part — the "Sign in with Google" login experience rather than just delegated access — that's the job of the thin layer built on top of OAuth: what is OpenID Connect explains the ID token that finally answers "who is this user."