RFC 6749 · · Proposed Standard
How apps get access without getting your password.
The official title is "The OAuth 2.0 Authorization Framework." What it actually decides: how one app can act on your behalf at another, the "Sign in with Google" flow, without ever seeing your actual password.
- Status
- Proposed standard
- Replaces
- RFC 5849
Written by Noel Lang · IT trainer
TL;DR
RFC 6749 defines OAuth 2.0, a framework for delegated access.
It lets an application obtain a scoped, revocable access token
to act on your behalf at another service, without ever seeing your password.
It is the machinery behind every “Sign in with” button and most third-party
API access. Being a framework, it defines the flows and leaves many security
details to companion specs like PKCE and the OAuth Security
BCP.
The problem it solves
Before OAuth, letting one service act on another meant handing over your username and password. Want a photo-printing site to pull pictures from your cloud storage? You typed your storage password into the print shop. Now it had everything, forever: it could read your photos, delete your account, change your password, and the only way to take that back was to change your password and hope nobody had copied it.
Passwords are all-or-nothing and effectively non-revocable. RFC 6749 replaces that with delegated access. You prove who you are once, directly to the service that already holds your password, and that service hands the app a token describing exactly what it may do and for how long. OAuth exists so you never have to give one app your password to another. The app never sees the password, and you can revoke the token from a settings page without touching anything else.
The tradeoff is honesty about what it is: OAuth 2.0 is a flexible framework, not one rigid protocol. Secure use depends on choosing the right flow and following later companions like RFC 7636 and the security best-practice documents.
The valet key analogy
A car often comes with two kinds of key. Your normal key does everything: drive it, open the trunk, reach the glovebox where the registration and the garage-door opener live. The valet key is deliberately less. It starts the engine and opens the door, but the trunk and glovebox stay locked. You hand it to a parking attendant you don’t fully trust, precisely because it can’t do much.
An OAuth access token is a valet key for your account. It is scoped (this app may read your calendar, not delete it), time-limited (it expires in an hour, not never), and revocable (take it back without re-cutting your master key, meaning without changing your password). The authorization server is the machine that cuts these limited keys, and your password is the master key you never hand out. You only ever show it to the one place allowed to cut valet keys.
The four grant types, honestly ranked
OAuth 2.0 is a framework, so it defines several ways to obtain a token, called grant types, for different kinds of client. It helps to see them ranked by how much you should trust them today:
- Authorization code is the main one, drawn below. A short-lived code is swapped for a token over a back channel, so the app never touches your credentials. This is what “Sign in with Google” uses. Combined with PKCE ( RFC 7636 ) it is also the right choice for mobile and single-page apps.
- Client credentials involves no user at all. A backend authenticates as itself to reach another service: a cron job calling an API, one microservice calling the next. This is the machine-to-machine grant.
- Implicit was a shortcut that returned the token straight to the browser with no code exchange, invented for JavaScript apps that couldn’t keep a secret. It is now discouraged; the Security BCP ( RFC 9700 ) says use the code flow with PKCE instead.
- Resource owner password credentials has the app collect your username and password and trade them for a token. This is OAuth wearing the exact costume it was built to abolish, and it survives only as a migration crutch.
Two of the four grant types exist mainly so we can tell you not to use them. Modern OAuth is really “the authorization code flow with PKCE,” plus client credentials for machines.
The four roles, before any flow
Every OAuth flow is a conversation between exactly four parties. Get these straight and the diagrams stop being confusing:
-
Resource owner usually you
The human who owns the data and is the only one allowed to grant access to it. When a printing app asks for your photos, you are the resource owner. Your job is one decision: approve or deny, once.
-
Client the app asking
The application that wants to act on your behalf. A confidential client (a web backend) can keep a secret; a public client (a mobile or single-page app) cannot, which changes which flow is safe for it. The client never sees your password.
-
Authorization server issues the tokens
Where you actually log in and consent. It already knows your password, so you only ever type it here. After you approve, it mints the access token. This is Google's, GitHub's or Apple's login and consent screen.
-
Resource server holds the data
The API that guards the protected resource and accepts the access token as proof of permission. Often the same company as the authorization server (Google is both), but not always. It checks the token on every request.
A key detail: the authorization server and the resource server are different roles, even when one company plays both. You log in at one and spend the token at the other.
The authorization code flow
The flow behind “Sign in with GitHub.” Watch where the two channels split: the front channel runs through your browser and carries only a one-time code, while the back channel is a direct server-to-server call that carries the actual token. Your password stays at the authorization server the whole time.
What the RFC actually says
The original is about 76 pages and reads more like a menu of options than a single recipe. The map, in case you want to visit the source:
| Section | In plain words |
|---|---|
| 1 · Roles & protocol flow | Introduces the four roles and the abstract token dance between them. This is the vocabulary the entire rest of the web reuses when it says "client" or "authorization server". |
| 1.3–1.5 · Grants & tokens | Names the four grant types and the difference between an access token (short-lived, shown to the API) and a refresh token (long-lived, kept private to get new ones). |
| 3 · Protocol endpoints | The two doors: the authorization endpoint (where you log in and consent) and the token endpoint (where a code is exchanged for a token), plus the client's redirection endpoint. |
| 4 · Obtaining authorization | Each grant type, step by step. Section 4.1 is the authorization code flow, the part almost everyone actually implements. |
| 6 · Refreshing a token | How a client trades a refresh token for a fresh access token when the old one expires, without dragging you back through the login screen. |
| 10 · Security considerations | A long, honest chapter about what the framework does not solve on its own. Its length is exactly why later best-practice documents (RFC 9700) had to be written. |
Things people get wrong
-
"Signing in with OAuth means OAuth logged me in."
Not quite. OAuth 2.0 authorizes, it does not authenticate. An access token proves an app is allowed to do something, never who the person is. The "who are you" layer is OIDC, a separate specification built on top of OAuth. "Sign in with Google" is really OpenID Connect riding on OAuth. Treating a bare OAuth access token as proof of identity is a classic and genuinely dangerous bug.
-
"The access token tells the app who I am."
It does not have to, and to the client it is meant to be opaque: a string it presents to the resource server, nothing it should try to read. Prying identity out of an access token is a category error. If you want identity, you ask for an ID token via OpenID Connect, which is a different token with a defined, verifiable format.
-
"OAuth 2.1 already replaced RFC 6749."
Not yet. OAuth 2.1 is still a draft that consolidates RFC 6749 with the practices that hardened it (PKCE required, the implicit and password grants removed). Until it is published as an RFC, 6749 is the standard, and 2.1 is a cleaner retelling of the same protocol, not a new one.
-
"A bearer token is encrypted, so logging it is fine."
A bearer token (
) is defined by one property: whoever bears it may use it, like cash. It is not necessarily encrypted, and if it leaks into a log file, a URL or a screenshot, anyone can spend it until it expires. That is exactly why it must travel only over TLS and must never be written to a log.
Where you'll meet OAuth
OAuth is the quiet machinery behind almost every 'connect your account' moment online. A field guide to spotting it:
| You see | You're probably looking at |
|---|---|
| "Sign in with Google / GitHub" | OAuth 2.0 doing delegated access, with OpenID Connect layered on for the identity part. The button is the single most common thing OAuth powers. |
| A consent screen listing permissions | "App X wants to: see your email address, read your repositories." Each of those bullet points is an OAuth scope you are about to grant. |
| ya29.… or gho_… | An access token in the wild. Google's often start with ya29., GitHub OAuth tokens with gho_. A string the client shows the API and otherwise treats as opaque. |
| kubectl or gcloud opening a browser | The device authorization grant (RFC 8628): OAuth for things that cannot easily pop a browser. A smart-TV app showing "go to example.com/activate, enter WXYZ" is the same flow. |
| GitHub → Settings → Applications | The list of clients you have granted tokens to, and the revoke button. This is the "revocable" promise made real: one click and the token is dead, no password change. |
| 401 with WWW-Authenticate: Bearer | A resource server rejecting a missing, expired or wrong access token. Defined by the bearer-token companion, RFC 6750. |
| An API key in a header | The thing OAuth is not. A static shared secret with no user, no scopes and no expiry by default. Simpler and blunter, and a different trust model entirely. |
Questions people actually ask
What problem does OAuth 2.0 solve? +
Delegated access. It lets you grant one app limited, revocable permission to use another (read your calendar, post on your behalf) without handing over your password. The app receives a scoped access token instead, and you can revoke it at any time without changing anything else.
Is OAuth 2.0 authentication or authorization? +
Strictly authorization: it decides what an app is allowed to do, not who you are. Logging in with it (authentication) is a separate job layered on top by OpenID Connect, which is built on OAuth 2.0 but is its own specification. This is the single most common OAuth mistake.
What is the difference between OAuth and OpenID Connect? +
OAuth 2.0 grants access to resources (authorization). OpenID Connect is a thin layer on top of it that adds identity (authentication): it returns an ID token that tells the app who you are. 'Sign in with Google' is really OpenID Connect riding on OAuth. 'Let this app read your Google Drive' is plain OAuth.
What is the difference between OAuth 2.0 and OAuth 2.1? +
OAuth 2.1 is an in-progress consolidation, not a replacement yet. It folds RFC 6749 together with the security best practices that hardened it (PKCE required, implicit and password grants removed). Until it is published, RFC 6749 remains the standard, and 2.1 is a tidier retelling of it rather than a new protocol.
What is the difference between OAuth 2.0 and SAML? +
Both delegate trust, but from different eras. SAML is XML-based and was built for enterprise single sign-on in the browser. OAuth 2.0 is JSON- and HTTP-based and was built for API access and mobile apps. For login specifically, OpenID Connect (built on OAuth) is the modern equivalent of what SAML did.
Is OAuth 2.0 still secure and current? +
Yes, RFC 6749 is still the current Proposed Standard, but you must pair it with later hardening. Use the authorization code flow with PKCE (RFC 7636), and follow the OAuth 2.0 Security Best Current Practice (RFC 9700, BCP 240, published 2025). The framework alone leaves security choices open; those documents close the dangerous ones.
What is the difference between an access token and a refresh token? +
An access token is the short-lived credential the app shows the API on each request; it usually expires in minutes to an hour. A refresh token is a longer-lived credential the app keeps privately and uses to obtain new access tokens, so it does not have to send you back through login when the access token expires.
How RFC 6749 connects
What came before
-
RFC 5849 (2010) was the original OAuth, and it required every request to be cryptographically signed, which was famously painful. RFC 6749 obsoletes it, moving the security burden onto TLS and a simpler token model.
What it works with
-
RFC 9110 · builds on
The HTTP it all runs over
Every OAuth message is an ordinary HTTP request: redirects, form posts, an Authorization header. OAuth adds no new transport, it just choreographs HTTP requests between four parties.
-
RFC 6750 · companion
How you actually use the token
RFC 6749 says how to get an access token; its twin RFC 6750 says how to spend one: put it in an <span class="font-mono text-sm">Authorization: Bearer</span> header. Bearer means whoever holds it can use it, so it must travel only over TLS.
-
RFC 7636 · hardens
PKCE, the fix for public clients
Mobile and single-page apps cannot keep a client secret, which once made the code flow interceptable. PKCE plugs that hole and is now mandatory for those clients. It is the reason the insecure implicit grant could be retired.
-
RFC 2119 · written in the language of
The MUST and SHOULD keywords
Every "the client MUST" and "the server SHOULD" in RFC 6749 has a precise meaning defined once, in RFC 2119. The framework's requirements are only as strong as that shared vocabulary.
Its counterparts
-
RFC 8252 · updated by
OAuth for native apps
Extends RFC 6749 with the right way to do OAuth in a mobile or desktop app: use the system browser, not an embedded web view, and require PKCE. One of the documents that officially updates 6749.
-
RFC 9700 · updated by
The security rulebook on top
<span class="text-neutral-500">(BCP 240, 2025)</span> is the OAuth 2.0 Security Best Current Practice. It formally updates RFC 6749 with a decade of hard-won advice: use the code flow with PKCE, drop the implicit and password grants, validate redirect URIs exactly.