Why was the implicit grant, which returned an access token straight from the authorization response, abandoned?
answer
- token came back on the visible leg
- response_type=token, no token endpoint
- a credential parked in a URL
- written for browsers that could not call cross-origin
- SHOULD NOT, unlike the password grant
basics
~20 sIt delivered the access token through the browser in the redirect's URL fragment, with no back-channel exchange and no standardised way to bind the token to anything. The constraint that justified it, a browser script unable to call the token endpoint, no longer exists.
solid answer
~50 sThe implicit grant used `response_type=token`: the authorization server put an `access_token` directly into the fragment of the redirect back to the client, and there was no token endpoint call at all. That means the usable credential itself travelled on the visible, browser-mediated leg, ending up somewhere the browser retains and can pass on, and it arrived without any exchange in which the client could be held to anything or the token bound to a key. It existed because scripts in browsers of the time could not reliably make the cross-origin call the code exchange needs; cross-origin requests removed that constraint. RFC 9700 says clients **SHOULD NOT** use it — a weaker wording than the password grant's MUST NOT — and the OAuth 2.1 draft removes it. Browser-based public clients use the authorization code grant instead.
code
http · 7 linesGET /authorize?response_type=token&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Forders.nursery.example%2Fcb
&scope=orders.read&state=af0ifjsldkj HTTP/1.1
Host: as.catalogue.example
HTTP/1.1 302 Found
Location: https://orders.nursery.example/cb#access_token=2YotnFZFEjr1zCsicMWpAA&token_type=Bearer&expires_in=3600&state=af0ifjsldkjgo deeper
Remember the headline: the old flow handed the access token back through the browser in the URL, and browser applications now use the code-based flow instead.
Explain the mechanics — response_type=token, no token endpoint call, the token in the redirect's fragment — and why removing the back-channel leg is the defect.
Add the history and the correct strength of the guidance, and be able to say what a browser-based public client does today and why that is not the same thing.
Treat it as a migration item with a date: identify which registered clients still request it, what each would need to move, and when the authorization server stops offering it.
## What the implicit grant did It was the redirect-based grant with the middle step deleted. The client sent the browser to the authorization endpoint with `response_type=token` instead of `response_type=code`; after the resource owner approved, the authorization server redirected the browser back with the `access_token`, its `token_type` and `expires_in` in the **fragment** of the redirect target. There was no token request, so `grant_type` never appeared: the flow ended at the redirect. ## Why it was there in the first place RFC 6749 was written when a script running in a page could not reliably make a request to a different origin, and the token endpoint is on the authorization server's origin, not the client's. Without a way to call it, an in-browser application could not complete a code exchange, so the specification offered a shape that finished on the front channel. That is an accommodation to a browser limitation, not a security design — and the limitation went away once cross-origin requests became ordinary. ## What is wrong with it | | Authorization code grant | Implicit grant | |---|---|---| | What the browser leg carries back | A code that is useless alone | The access token itself | | Is there a back-channel exchange? | Yes, at the token endpoint | No | | Where the usable credential ends up | In the client's own request and response | In a URL the browser holds and may pass on | | Binding the token to a key | Possible, through the exchange | No standardised way | The first row is the substance. The code grant is deliberately arranged so that the thing visible to the browser is not the thing that opens the resource server. The implicit grant inverts that: the credential itself becomes part of a URL, which is a place designed for retention and for sharing rather than for secrets. And because nothing happens after the redirect, there is no point in the flow at which the client interacts with the authorization server directly — so the exchange cannot be used to establish anything further about the request. ## Read the strength of the rule correctly RFC 9700's wording on the implicit grant is that clients **SHOULD NOT** use it. That is deliberately weaker than its MUST NOT on the resource owner password credentials grant, and an answer that gives them the same strength is teaching a false certainty. The OAuth 2.1 draft is what removes both. Interviewers who know the material listen for this distinction, because it separates a candidate who has read the guidance from one who has heard that "the old grants are gone". ## What replaces it A browser-based public client — an application whose code is delivered to the user's device and therefore cannot keep a secret — uses the **authorization code grant**. It cannot authenticate itself with a secret, but that was never what the code exchange existed for: the code still comes back on the front channel, and the client still redeems it at the token endpoint, on a cross-origin call that is now unremarkable. A separate proof-key extension covers what a public client does in place of a secret. Two confusions to clear up: 1. **"Implicit" is not "no client secret".** A public client using the authorization code grant is not doing implicit; the distinguishing feature of implicit was where the token came from, not whether the client had a secret. 2. **"The fragment is never sent to the server" is true, and is not a defence.** It is true that a fragment is not transmitted in the request line. The token still lands in the browser's address bar, in whatever the page does with it, and in anything that handles that URL afterwards — which is exactly the exposure the code grant avoids by never putting a token there. ## What to say in an interview Name the mechanism (`response_type=token`, token in the redirect's fragment, no token endpoint call), name the historical reason it existed (no cross-origin call available), name the defect (the usable credential on the visible leg, no exchange to build on), state the strength correctly (SHOULD NOT in current guidance, removed in the 2.1 draft), and give the replacement (the authorization code grant, including for public clients).
- Why did the implicit grant exist at all?Because a script in a browser of that era could not reliably make a request to another origin, and the token endpoint lives on the authorization server's origin. Without that call an in-browser client could not complete a code exchange, so the specification offered a flow that finished on the front channel. Cross-origin requests removed the constraint.
- Is 'implicit' just the authorization code grant without a client secret?No. A public client with no secret can and does use the authorization code grant: the code still comes back through the browser and is still redeemed at the token endpoint. What made the implicit grant different is that the access token itself came back in the redirect and there was no token endpoint call.
- A colleague argues the fragment is safe because it is never sent to a server. Is that right?The premise is true and the conclusion is not. A fragment is not transmitted in the request line, but the access token is still in the address bar, in whatever the page does with it, and in anything that later handles that URL. The code grant avoids the whole question by never putting a token there.
saying these in an interview costs you the question
- Calls the implicit grant the standard flow for browser applications
- Thinks keeping the token in the fragment makes it safe
- Confuses the implicit grant with a public client's code flow
- Gives it the same prohibition strength as the password grant
- Says the implicit grant avoided the redirect entirely