No. For new apps, use the authorization code flow with PKCE instead. The current OAuth security best practice, RFC 9700, says clients should not use the implicit grant or any response type that returns an access token in the authorization response, because those tokens can leak and be replayed.
What the implicit flow is
In the implicit flow (response type token), the authorization server sends the access token straight back in the redirect to the app. There is no separate back channel call to the token endpoint. It was a shortcut for browser based apps, trading a back channel call for simplicity.
RFC 9700 says technology has changed since then, and the security model the shortcut relied on no longer holds up.
Why it was dropped
RFC 9700 describes the implicit grant and other response types that issue access tokens in the authorization response as vulnerable to access token leakage and access token replay. The token travels through the browser address bar and history, can be read by scripts and extensions, and can be injected into the client by an attacker.
The RFC also notes that the way browsers treat fragments during redirects has changed, which weakened the security model the implicit flow was built on.
What to use instead
| Situation | Use |
|---|---|
| Browser app with a backend you control | Authorization code flow with PKCE, handled by the backend |
| Browser app with no backend | Authorization code flow with PKCE in the browser |
| Native or mobile app | Authorization code flow with PKCE in the system browser |
| Legacy app already on implicit | Plan a migration, see the steps below |
The code flow returns a short lived code in the redirect. The app then exchanges the code at the token endpoint, along with the PKCE verifier. An attacker who sees the redirect gets a code that is useless without the verifier.
Migration steps
- Check that your authorization server supports the code flow with PKCE for public clients. RFC 9700 recommends authorization servers advertise PKCE support in their metadata.
- Register the same redirect URIs for the new flow, with exact matching.
- Change the request from
response_type=tokentoresponse_type=codeand add a code challenge. - Add a call from the app to the token endpoint that sends the code and the verifier.
- Remove token parsing from the URL fragment.
- Once all users are on the new build, disable the implicit grant for that client.
When implicit is still defensible
RFC 9700 says clients should not use it "unless access token injection in the authorization response is prevented" and the leakage risks are mitigated. That is a high bar. If you cannot show how you meet it, treat the answer as no.
One related detail: the OpenID Connect flows that return only an ID token in the redirect are a different case from returning an access token. The BCP's concern is about access tokens in the authorization response.
Quick check
Is the implicit flow removed from OAuth?
It is still described in RFC 6749, but RFC 9700 advises against using it. Many servers keep it available for older clients.
Does PKCE only matter for mobile apps?
No. RFC 9700 says public clients must use PKCE with the code flow, and recommends it for confidential clients as well.
Safeguard's SBOM and dependency scanning can show which OAuth client libraries are in your tree and whether any carry known advisories. You can try a free scan.
Sources
Last reviewed: 19 October 2026.
