skip to content

Which two RFC 6749 grants does OAuth 2.1 remove outright, and what got each of them removed?

level: middleimportance: must knowfreq 62%

answer

  1. two grants gone, not deprecated
  2. one returned the token via the browser
  3. one put the password in the client
  4. SHOULD NOT and MUST NOT came earlier
  5. 2.1 is what stops defining them

basics

~20 s

OAuth 2.1 removes the implicit grant and the resource owner password credentials grant. Implicit handed an access token back through the browser with no code exchange; the password grant required the client to handle the resource owner's own password.

solid answer

~40 s

OAuth 2.1 deletes two of RFC 6749's grants rather than deprecating them: the **implicit** grant and the **resource owner password credentials** grant. Implicit returned an `access_token` in the authorization response itself, so the token travelled back through the browser and there was no authenticated second leg at which the authorization server could tell who was redeeming it. The password grant had the client collect the resource owner's password, which is the delegation OAuth exists to remove, and it freezes authentication at whatever the client's own form can collect. Both were already written down as bad practice: RFC 9700 §2.1.2 says clients SHOULD NOT use the implicit grant and §2.4 says the resource owner password credentials grant MUST NOT be used. OAuth 2.1 is what takes the further step of not defining them at all.

code

http · 11 lines
http
POST /token HTTP/1.1
Host: as.allotment-society.example
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

grant_type=password&username=plot42&password=Sp4deAndFork&scope=plots.read

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error":"unsupported_grant_type"}

go deeper

for a junior

Recall that OAuth 2.1 dropped two flows an older tutorial may still teach, and that anything handing an access token straight back to a browser page is the first of them.

for a middle

Explain what each removed grant did and what was wrong with it: a token delivered in the authorization response with no authenticated redemption leg, and a client holding the resource owner's password.

for a senior

Say where the strength came from — advice in a best current practice versus removal from the framework — and know that a running server may still accept both regardless of what it claims.

for a principal

The hard part is not technical: dropping the password grant moves the login screen out of your product and into the provider, which is a product decision with a deprecation schedule attached to it.

## What removal actually means OAuth 2.1 is a consolidation of the OAuth 2.0 authorization framework with the documents written after it, and one of its most visible effects is subtractive. Two of the authorization grants RFC 6749 defined are simply absent: the **implicit** grant and the **resource owner password credentials** grant. They are not marked obsolete, not parked in an appendix, and not gated behind a flag a server may still switch on. There is no definition left to conform to. That distinction is where most answers lose precision, because the objections to both grants were written down years before 2.1, and the *strength* of that earlier wording is not the same as removal. | Statement | Where it is written | Requirement level | |---|---|---| | Clients SHOULD NOT use the implicit grant | RFC 9700 §2.1.2 | SHOULD NOT | | The resource owner password credentials grant MUST NOT be used | RFC 9700 §2.4 | MUST NOT | | Neither grant is defined | OAuth 2.1 | absent | A candidate who says the security best current practice *bans* the implicit grant has promoted a SHOULD NOT. A candidate who says 2.1 *deprecates* the two grants has demoted a deletion. Saying which document carries which strength is the signal an interviewer is listening for here. ## Why the implicit grant went The implicit grant returned an `access_token` in the authorization response itself, so the token came back through the user agent rather than over a server-to-server call. Three consequences follow, and all three are about the container rather than the cryptography: 1. **The value comes to rest in places nobody audited.** It passes through the address bar and lands in browser history; it can reach a referrer header, an analytics beacon, a crash report or a proxy log. Transport security protects the hop, not the places the token settles afterwards. 2. **There is no authenticated leg at which to catch a misdelivery.** Because the response *is* the token, there is no later request where the authorization server can apply client authentication or bind what it issued to the flow that asked for it. 3. **No `refresh_token` is issued in this grant**, so deployments compensated with long access-token lifetimes — lengthening the window in which an exposed token is still useful. The grant also had a justification that expired. It existed because a browser application of the era could not reliably make a cross-origin call to the `token_endpoint`. Once that became routine, the authorization-code grant became available to exactly the clients implicit was invented for, and the trade it offered stopped being a trade. ## Why the resource owner password credentials grant went This grant had the client collect the resource owner's own password and post it to the `token_endpoint`. The objection is structural rather than statistical: - It reverses the point of the framework. OAuth exists so a client can act on one slice of an account **without ever seeing the account's password**; this grant hands over the whole credential. - It freezes authentication at whatever the client's form collects. A provider that wants a second factor, a step-up challenge, a risk check or a consent screen cannot add one, because the client owns the login screen and the provider never meets the user. - It cannot federate. A password can only be forwarded to the party that actually holds it, which rules out every case where the resource owner's account lives somewhere the client does not control. - It teaches the wrong habit, training users to type their password into whatever asks for it. RFC 6749 already framed the grant as an aid for legacy clients. A decade of tutorials treated it as the simple option, which is why it is still the flow most often found running in a small, long-lived site whose login was wired up once and never reopened. ## The first-party defence, and what it misses The usual objection to removal is that the application is first-party: the resource owner is typing their password into the same organisation that holds the account, so nothing is delegated to a stranger. Even granting the trust argument, the cost does not go away. - The provider still cannot introduce an authentication step that did not exist when the client was written. - The password is still handled, logged and crash-reported by a second codebase. - The moment a second client appears, or the organisation federates its own login, the flow has to be replaced anyway. Removal is what stops that argument being reopened once per integration. ## What this looks like in a running system An authorization server can keep offering either grant long after a team says it is on 2.1, because a deployment decides what it accepts while the specification only decides what conformance means. So the two claims are separate and each needs its own evidence: that the server no longer offers the grant, and that no client still asks for it.

  • Removing the password grant takes away the only flow where the client owned the login screen. What does a first-party application do instead?
    It runs the authorization-code grant against the same authorization server, so the login screen belongs to the provider. That is what lets the provider add a second factor, a step-up challenge or a risk check without every client shipping a release — and it is why the password grant blocked those features rather than merely being risky.
  • RFC 9700 says clients SHOULD NOT use the implicit grant. Why is quoting that as 'the implicit grant is forbidden' a precision error?
    SHOULD NOT is strong advice with an acknowledged escape hatch: an implementer may deviate if they understand the consequence. Removal is not advice — OAuth 2.1 simply does not define the grant, so there is nothing to deviate from. The two statements carry different strengths, and an interviewer listening for precision hears the difference.

saying these in an interview costs you the question

  • Says the implicit grant is safe as long as the site uses TLS.
  • Calls the password grant acceptable because the application is first-party.
  • Thinks 2.1 deprecates the two grants but still defines them.
  • Claims RFC 9700 already forbade the implicit grant outright.
  • Believes the client credentials grant was removed as well.