Type OAuth implicit flow deprecated into a search engine and every answer agrees. The community reference site oauth.net, loaded on 18 September 2026, puts it in one line: “It is now deprecated and should not be used in new applications.” That advice is sound. The word carrying it is not as solid as it looks.
Deprecated is not one of the IETF’s requirement keywords, and the four documents that actually govern the implicit grant use four different strengths of language about it. The spec that defined the grant in 2012 never uses the word. The OAuth 2.0 Security BCP says SHOULD NOT, with an escape clause. The OAuth 2.1 draft, still a draft, says omitted and credits the deprecation to someone else. Only one document, RFC 10017, published in August 2026, says MUST NOT without conditions, and it says it twice. So the sentence everyone repeats, that the implicit flow is deprecated, is strictly true in exactly one document, and that document is less than two months old.
This piece reads each one in its own words. Every quotation was matched against the raw text of its source on 18 September 2026, and every status is dated, because two of these documents are still moving.
“Deprecated” Is Not a Keyword, So Ask a Different Question
IETF documents state requirements with a fixed vocabulary defined in RFC 2119 and clarified by RFC 8174. The two words that matter here are defined very differently. MUST NOT means “that the definition is an absolute prohibition of the specification.” SHOULD NOT means “that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.” RFC 8174 adds that the words carry those meanings “only when they are in all capitals.”
Deprecated appears in neither list. It is ordinary English in an RFC, which is why it can mean anything from a mild preference to outright removal. So whether the implicit flow is deprecated is the wrong question to ask. The useful one has three parts: which document, which keyword, and for which kind of client.
| Document (status, checked 18 Sep 2026) | Its own operative words on the implicit grant | Uses deprecat- about it? | Strength |
|---|---|---|---|
| RFC 6749, Proposed Standard, Oct 2012 | Defines it; says its convenience “should be weighed” against the risk; one MUST NOT scoped to sign-in misuse | No (zero matches) | Advisory, lowercase |
| RFC 9700, BCP 240, Jan 2025 | Clients SHOULD NOT use it “unless” two conditions are met | Not about the grant by name | Conditional SHOULD NOT |
| draft-ietf-oauth-v2-1, Active Internet-Draft, rev 16 | “omitted from OAuth 2.1” | Once, attributing it to RFC 9700 | Not a standard, so no force yet |
| RFC 10017, BCP 212, Aug 2026 | Authorization server MUST NOT issue tokens in the authorization response; browser clients MUST NOT use the grant | Once, in §7.2.3 | Unconditional MUST NOT, twice |
The rest of this article takes the rows one at a time, then puts them on a single timeline, because the order in which the words were written is not the order in which they became standards.
RFC 6749 Knew the Cost in 2012 and Said So
The original OAuth 2.0 framework did not present the implicit grant as a trick. It presented it as a trade. Its definition names the benefit first: “Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token.” Then the cost: “However, this convenience should be weighed against the security implications of using implicit grants, such as those described in Sections 10.3 and 10.16, especially when the authorization code grant type is available.”
That should is lowercase. It is advice about judgement, not a requirement keyword. The risk itself is stated plainly in §10.3: “When using the implicit grant type, the access token is transmitted in the URI fragment, which can expose it to unauthorized parties.”
RFC 6749 does contain one capitalised prohibition about the grant, and it is narrow. §10.16 says that “Any specification that uses the authorization process as a form of delegated end-user authentication to the client (e.g., third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use”. That is a rule about building sign-in on top of OAuth, not about SPAs calling APIs. A case-insensitive search of the whole RFC for deprecat returns nothing.
Why did the grant exist at all? RFC 10017’s own history section answers: the authorization server usually lived on another domain, “so it was historically not possible to use the Authorization Code grant type (Section 4.1 of [RFC6749]), which would require a cross-origin POST request.” Skipping the code exchange was how a browser app got a token at all.
The Historic Note Credits the Browser, Not a New Risk
RFC 10017 gives the grant a fair hearing in a subsection titled Historic Note. It opens: “Historically, the Implicit grant type provided an advantage to browser-based applications since JavaScript could always arbitrarily read and manipulate the fragment portion of the URL without triggering a page reload.” It then adds the cross-origin constraint: “Additionally, until CORS was widespread in browsers, the Implicit grant type offered an alternative flow that didn’t require CORS support in the browser or on the server.”
What changed, by the note’s account, is the browser. “Modern browsers now have the Session History API”, which lets an app strip an authorization code from the URL without a reload, and “CORS has widespread support and is often used by single-page applications for many purposes.” Nothing in the note says the risk of a token in a URL was discovered later. RFC 6749 had written that down in 2012. The advice changed because the alternative became possible, not because the danger became new.
The note was not always this complete. In the first draft of what became RFC 10017, draft-parecki-oauth-browser-based-apps-00, dated 2 November 2018, it was one short paragraph about fragments:
Historically, the Implicit flow provided an advantage to single-page apps since JavaScript could always arbitrarily read and manipulate the fragment portion of the URL without triggering a page reload.
It ended: “so this overloaded use of the fragment portion is no longer needed.” The CORS reason was already in the draft’s overview by December 2022 at the latest, but it joined the note itself only in revision -13, dated 13 March 2023. The version most people now quote is the note’s 2023 form.
RFC 9700 offers a different technology argument in its introduction: “Technology has changed. For example, the way browsers treat fragments when redirecting requests has changed, and with it, the implicit grant’s underlying security model.” It does not say what the earlier behaviour was, and the research behind this hub could not find a primary source that does. It is reported here as RFC 9700’s own claim, not as an established history.
November 2018: A MUST NOT and a SHOULD NOT, One Week Apart
Here is the part the tidy story leaves out. The strongest and the weakest modern positions were both written in the same month, by overlapping people, and neither became a standard for years.
2 November 2018. The first browser-apps draft already said: “The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required according to Section 6), so clients and authorization servers MUST NOT use the Implicit Flow for browser-based apps.” The unconditional MUST NOT that RFC 10017 carries today was there on day one. Only its stated reason changed.
15 October 2018. The Security BCP draft, draft-ietf-oauth-security-topics-08, still permitted the grant with conditions: “Clients utilizing the implicit grant SHALL either use [I-D.ietf-oauth-token-binding] in order to allow the RS to detect and prevent attempts to inject (replay) access tokens or consider use of alternative grant types supporting injection detection”.
9 November 2018. Revision -09 turned that around: “In order to avoid these issues, Clients SHOULD NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response.” No escape clause. Its changelog: “changed text to recommend not to use implicit but code”. The same day, Torsten Lodderstedt, the BCP’s lead author, published Why you should stop using the OAuth implicit grant!. It opens: “No one should any longer use the implicit grant!” and explains that “The decision was met during the IETF meeting this week in Bangkok.” He called the grant’s security “broken beyond repair.”
28 December 2018. Revision -11 added the escape clause. The sentence now ended “unless the issued access tokens are sender-constrained and access token injection in the authorization response is prevented.” The changelog gives the reason in one line: “Adapted section 2.1.2 to outcome of consensus call”.
So the unconditional SHOULD NOT that launched the deprecation story lasted forty-nine days in the drafts. This is not a gotcha. A working group changing a sentence after a consensus call is the process doing its job, and Lodderstedt’s post was accurate about the draft on the day he wrote it. The argument behind the consensus call would be in the OAuth working group’s mailing list for December 2018. The archive’s search refused automated requests on 18 September 2026, so that argument is not reported here.
By May 2019, Okta’s developer blog, in a post by Aaron Parecki, summed it up for developers: “The OAuth Working Group has published some new guidance around the Implicit flow and JavaScript-based apps, specifically that the Implicit flow should no longer be used.” That was true, and the guidance it described was two Internet-Drafts. The Security BCP would not become an RFC until January 2025. The browser-apps draft would not until August 2026. For roughly six years, the most confidently repeated sentence in OAuth security rested on work in progress.
RFC 9700 Leaves a Door Open, and Says Exactly Where
When the Security BCP was published as RFC 9700 in January 2025, its operative sentence read:
In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type token) or other response types issuing access tokens in the authorization response, unless access token injection in the authorization response is prevented and the aforementioned token leakage vectors are mitigated.
Read it with RFC 2119 open beside it. SHOULD NOT already allows for valid exceptions. The unless clause names two of them: stop token injection, and mitigate the leakage vectors the section cites. The paragraph before the escape clause also narrows the door: “Moreover, no standardized method for sender-constraining exists to bind access tokens to a specific client (as recommended in Section 2.2) when the access tokens are issued in the authorization response.” The December 2018 wording had named sender-constraining as a condition. The published wording names outcomes instead, and admits that one of the usual tools for reaching them is not standardized for this case.
The sentence also covers more than the classic grant. It applies to any response type that returns an access token from the authorization endpoint. It then recommends “the response type code” or response types such as code id_token that deliver tokens from the token endpoint.
Where does RFC 9700 use the word deprecate? A case-insensitive search returns three matches, and printing them matters more than the count. Two are the same general claim, in the abstract and the introduction: “Further, it deprecates some modes of operation that are deemed less secure or even insecure.” Neither names the implicit grant. The third is a bibliography title, Deprecating TLS 1.0 and TLS 1.1. RFC 9700 never calls the implicit grant deprecated in so many words. Its judgement is the SHOULD NOT.
One more fact shapes how most engineers meet this. RFC 9700 formally updates RFC 6749. The IETF datatracker’s page for RFC 6749, loaded 18 September 2026, shows three documents under Updated by: RFC 8252, RFC 8996 and RFC 9700. RFC 10017 does not appear in that list, and its header carries no Updates line. A reader who starts from the base specification and follows the official chain reaches the conditional SHOULD NOT. Nothing on that path leads to the MUST NOT.
RFC 8252, one of the documents in that list, adds a fifth voice for a different client type. The native-apps BCP of October 2017 says, in §8.2: “However, as the implicit flow cannot be protected by PKCE [RFC7636] (which is required in Section 8.1), the use of the Implicit Flow with native apps is NOT RECOMMENDED.” Under RFC 2119, NOT RECOMMENDED is the same strength as SHOULD NOT. RFC 8252 is also BCP 212, the label RFC 10017 now shares. One BCP number now holds a SHOULD NOT-strength rule for native apps and a MUST NOT for browser apps, so cite RFC numbers, never the BCP alone.
OAuth 2.1 Says “Omitted”, and It Is Still a Draft
Most summaries say the implicit grant was removed in OAuth 2.1, as if 2.1 were a standard. On 18 September 2026 the IETF datatracker lists draft-ietf-oauth-v2-1 as an “Active Internet-Draft” at revision 16, last updated 2 September 2026. Its intended RFC status reads “(None)”, its IESG state reads “I-D Exists”, and the working group’s milestone for submitting it to the IESG is December 2026. The same page’s history records the draft expiring three times between revisions, in January 2021, November 2024 and May 2025.
What the draft says is precise. Its own verb is omit. The current revision’s §10.1, Removal of the OAuth 2.0 Implicit grant, reads: “The OAuth 2.0 Implicit grant is omitted from OAuth 2.1 as it was deprecated in [RFC9700].” It then scopes the removal: “This value for the response_type parameter is no longer defined in OAuth 2.1.” And it limits it: “Removal of response_type=token does not have an effect on other extension response types returning other artifacts from the authorization endpoint, for example, response_type=id_token defined by [OpenID.Connect].”
The one time the draft says deprecated, it hands the word to RFC 9700, a document whose own sentence on the grant is a conditional SHOULD NOT and never uses the word about it. That is a fair summary of RFC 9700’s judgement. It is not a quotation of it, and it should be cited as the 2.1 draft’s characterisation, not as RFC 9700’s words.
The citation itself has a history, and it runs through the archive:
- 7 March 2020. The first individual draft,
draft-parecki-oauth-v2-1-00, does not mention the implicit grant at all. The grant is simply absent. - 30 July 2020. Working-group revision -00 adds a line saying the grant “is omitted from this specification as per Section 2.1.2 of [I-D.ietf-oauth-security-topics]”, the Security BCP, still a draft.
- 7 March 2022. Revision -05 adds the dedicated section, saying the grant “was deprecated in” the same Internet-Draft. A draft cited another draft for a deprecation.
- 28 May 2025. Revision -13 swaps the reference to
[RFC9700], four months after that RFC was published.
The author lists explain why none of this is a quarrel. The 2.1 draft’s authors are Dick Hardt, Aaron Parecki and Torsten Lodderstedt. RFC 9700’s lead author is Lodderstedt, and RFC 10017’s is Parecki. These are not rival camps. They are overlapping people writing different kinds of document: a general security BCP, a framework rewrite, and a profile for one type of client. Each uses the strength of language its own scope allows.
RFC 10017 Is the Only Unconditional MUST NOT, and It Says It Twice
The browser-apps BCP handles the grant in §7.2, and the paragraph starts softly: “The security properties of the Implicit grant type make it no longer a recommended best practice.” One sentence later it becomes absolute:
To effectively prevent the use of this flow, the authorization server MUST NOT issue access tokens in the authorization response and MUST issue access tokens only from the token endpoint. Browser-based clients MUST use the Authorization Code grant type and MUST NOT use the Implicit grant type to obtain access tokens.
Two MUST NOTs, aimed at two parties. The first binds the authorization server, which is the part most migration guides skip. The second binds the client. Neither has an unless.
Two limits keep this honest. First, scope: RFC 10017 is a profile for browser-based applications, not a restatement of OAuth for every client type. Second, vocabulary. The RFC’s §7 is titled Discouraged and Deprecated Architecture Patterns, but its body text never uses discouraged outside that title, and uses deprecation exactly once, in §7.2.3, tied to this grant alone: “there are a few additional attacks that further support the deprecation of the Implicit grant type.” The other patterns under the same title get their own verdicts. The password grant gets a MUST NOT that points back to RFC 9700, and running the OAuth flow in a service worker gets “not recommended”. Do not spread deprecated across the whole section.
A small counting warning for anyone checking this at home: a case-insensitive search for implicit in RFC 10017 returns 20 matches, and one of them is inside the word simplicity. Print the matches before quoting a number.
What PKCE Fixed, and What It Never Claimed to Fix
The migration everyone recommends is authorization code plus PKCE, so it helps to know what PKCE was built for. The abstract of RFC 7636 (September 2015) names one attack: “OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack.” Its introduction describes that attack on a phone: “the native application running on the end device, such as a smartphone”, whose redirect “typically uses a custom URI scheme” that a malicious app can also register. The word browser appears twice in RFC 7636, both times inside that native-app scenario. JavaScript, XSS and cross-site appear zero times.
PKCE became the browser answer for a different reason. RFC 8252 had already given it: the implicit flow “cannot be protected by PKCE”. Once CORS made the code exchange possible in a browser, code plus PKCE replaced the grant that could not be protected. RFC 10017 §4 describes the benefit: “Furthermore, adding Proof Key for Code Exchange (PKCE) [RFC7636] to the flow prevents authorization code injection as well as ensures that even if an authorization code is intercepted, it is unusable by an attacker.”
That closes the URL-leak and interception problems. It does not touch an attacker whose script already runs in your origin. RFC 10017 §5.1.3 describes that attacker opening a hidden frame and running a fresh, silent authorization code flow of its own, where “the attacker’s Authorization Code flow is indistinguishable from a legitimate Authorization Code flow.” The section’s own summary: “In essence, even if the application finds a token storage mechanism that is able to completely isolate the stored tokens from the attacker, the attacker will still be able to request a new set of tokens.”
So retiring the implicit grant fixed the problem the implicit grant had. It did not fix the problem every in-browser OAuth client has. Moving tokens out of the browser altogether, the backend-for-frontend pattern at the centre of this series, answers that second problem. The architecture, its threat model and its costs are covered in the companion pieces.
The Record, in Order
Standards publication dates and draft dates tell different stories, so here they are together. Draft dates are the documents’ own header dates.
| Date | Document | What it said about the implicit grant |
|---|---|---|
| Oct 2012 | RFC 6749 | Defined it; weigh the convenience against the risk; one scoped MUST NOT for sign-in misuse |
| Sep 2015 | RFC 7636 (PKCE) | Silent on implicit; fixes code interception for public clients |
| Oct 2017 | RFC 8252 (native apps) | NOT RECOMMENDED for native apps, because PKCE cannot protect it |
| 15 Oct 2018 | Security BCP draft -08 | Permitted, if clients SHALL use token binding or consider alternatives |
| 2 Nov 2018 | Browser-apps draft, first version | MUST NOT for browser apps; Historic Note covers fragments only |
| 9 Nov 2018 | Security BCP draft -09 | Unconditional SHOULD NOT; Lodderstedt’s post the same day |
| 28 Dec 2018 | Security BCP draft -11 | Escape clause added, “outcome of consensus call” |
| 7 Mar 2020 | First OAuth 2.1 draft | Implicit not mentioned |
| 30 Jul 2020 | OAuth 2.1 WG -00 | “omitted”, citing the Security BCP draft |
| 17 May 2021 | Browser-apps draft -08 | The name “backend for frontend” first appears |
| 13 Mar 2023 | Browser-apps draft -13 | CORS sentence joins the Historic Note |
| 23 Oct 2023 | Browser-apps draft -15 | Section retitled Discouraged and Deprecated; patterns ranked in “decreasing order of security” |
| Jan 2025 | RFC 9700 | Conditional SHOULD NOT becomes a Best Current Practice |
| 28 May 2025 | OAuth 2.1 draft -13 | Deprecation citation switched to RFC 9700 |
| Aug 2026 | RFC 10017 | Unconditional MUST NOT becomes a Best Current Practice |
| 2 Sep 2026 | OAuth 2.1 draft -16 | Still an Active Internet-Draft (checked 18 Sep 2026) |
Read down the strength column rather than the date column and the pattern is plain. The MUST NOT and the SHOULD NOT were written a week apart in 2018. What took eight years was publication, not conviction.
Saying It Accurately in a Design Review
If you are writing the migration ticket, or answering the reviewer who asks why, the accurate sentences are short:
- For a browser-based app, cite RFC 10017 §7.2: browser-based clients MUST NOT use the implicit grant, and authorization servers MUST NOT issue access tokens in the authorization response. That is the only unconditional form, and it binds your authorization server configuration too.
- For OAuth generally, cite RFC 9700 §2.1.2: a SHOULD NOT, with an escape clause for prevented injection and mitigated leakage. Include the escape clause; a reviewer who knows the RFC will ask about it.
- For OAuth 2.1, say the draft omits the grant, and keep the word draft. As of 18 September 2026 there is no OAuth 2.1 RFC.
- For RFC 6749, say nothing was deprecated. It told you to weigh the trade, and told you what the trade was.
None of this softens the conclusion. The implicit grant is finished for new browser work, and the one document that says so without conditions is the one written specifically for browsers. The precision matters because the people you are persuading will check the citation, and a correct citation survives that check.
❓ Frequently Asked Questions
Is the OAuth implicit flow deprecated?
For browser-based applications, RFC 10017 (August 2026) prohibits it outright: browser clients MUST NOT use it, and authorization servers MUST NOT issue access tokens in the authorization response. For OAuth in general, RFC 9700 (January 2025) says clients SHOULD NOT use it unless injection is prevented and leakage is mitigated. RFC 6749 never used the word, and the OAuth 2.1 document that omits the grant is still an Internet-Draft.
Did OAuth 2.1 deprecate the implicit grant?
No, for two reasons. OAuth 2.1 is not yet an RFC: on 18 September 2026 draft-ietf-oauth-v2-1 was an Active Internet-Draft at revision 16. And its own verb is omitted. Its one use of deprecated credits the deprecation to RFC 9700.
Was the implicit grant a mistake?
Not by the standards’ own account. RFC 6749 named the risk of a token in a URL fragment in 2012, and RFC 10017’s Historic Note explains that the grant existed because browsers could not yet make the cross-origin POST the code flow needs. When the Session History API and widespread CORS arrived, the alternative became possible. The judgement changed because the constraint went away, not because the risk was newly found.
Does switching to authorization code with PKCE make a single-page app secure?
It closes the problems the implicit grant had: tokens in URLs, code interception and code injection. It does not stop script already running in your origin from starting its own silent flow and getting fresh tokens, which RFC 10017 §5.1.3 describes. That is a separate problem, and it is why some architectures keep tokens out of the browser entirely.
Why does RFC 9700 still allow the implicit grant under conditions?
Its December 2018 draft changelog records the escape clause as the “outcome of consensus call”, and the reasoning would be in the OAuth working group’s mailing list for that period, which could not be retrieved for this article. What the RFC does say is where the door is: token injection must be prevented and the listed leakage vectors mitigated. It also notes that no standardized method exists to sender-constrain tokens issued in the authorization response.
Does this affect OpenID Connect’s id_token response type?
Not directly. RFC 9700’s SHOULD NOT covers response types that return access tokens from the authorization endpoint, and it names code id_token as an acceptable alternative. The OAuth 2.1 draft says removing response_type=token does not affect extension response types such as response_type=id_token. Check what your authorization server returns from the front channel, not what the flow is called.
📦 Recommended Resources
Some links below are Amazon affiliate links. If you buy through them this site earns a small commission at no extra cost to you.
For this question the free primary documents beat every book, because the whole answer lives in their exact wording. Read RFC 10017 §7.2 and its Historic Note, then RFC 9700 §2.1.2 with its escape clause, then RFC 2119, which is one page long and defines what MUST NOT and SHOULD NOT actually mean. For OAuth 2.1, use the IETF datatracker’s document page rather than any blog post, because it shows the current revision and status on the day you look. Every revision of the Security BCP draft is still in the IETF archive, so you can open revision -09 and revision -11 side by side and watch its implicit-grant sentence gain its escape clause. RFC 7636 is short and worth reading in full to see what PKCE was designed against.
The books below are for the layer around those documents.
- OAuth 2 in Action by Justin Richer and Antonio Sanso (Manning, March 2017). The clearest book-length explanation of OAuth 2.0’s moving parts. It was published before either of the November 2018 drafts discussed above, which makes it a useful baseline for how the framework was taught before the advice on browser clients moved. Richer is among the contributors RFC 10017 thanks by name. Manning’s page, checked 18 September 2026, lists no newer edition.
- API Security in Action by Neil Madden (Manning, November 2020). A broader book on securing APIs, including the token formats a browser client ends up holding. Read it for the server side of the argument: what an API should assume about a token it receives. Madden is among the people RFC 9700 acknowledges. Manning’s page, checked 18 September 2026, lists no newer edition.
- Grokking Web Application Security by Malcolm McDonald (Manning, May 2024). Manning describes it as covering browser security, including the same-origin policy and cookie security, and browser vulnerabilities such as cross-site scripting and cross-site request forgery. That is the ground the implicit grant was built on, and the ground the problem PKCE leaves behind lives on.
✅ Pro tip: When someone tells you a feature is deprecated, ask two questions: in which document, and with which keyword. If the answer is a blog post and the word deprecated, open the RFC it should have cited and find the capitalised sentence. That sentence, with its section number, is the one that will survive a security review.