OAuth 2.1 Migration: A Practical Runbook for Removing Implicit Grant and Adding PKCE

Implicit Grant (response_type=token) returns the access token directly in the browser's URL fragment as part of the redirect back from the authorization server, with no authorization code and no token exchange step in between. That design has three concrete problems. First, a token in a URL fragment can end up in browser history, in referrer headers sent to third-party scripts on the redirect page, and in server access logs if any intermediate hop logs the full URL. Second, there is no client authentication step at all, so any party that can intercept the redirect gets a usable token immediately, with nothing further to steal. Third, because there is no authorization code, there is nothing for PKCE to protect; PKCE works by binding the code exchange to a secret the client generated before redirect, and Implicit Grant has no exchange step to bind. OAuth 2.1 formalizes what identity providers have recommended since RFC 9700: every client, public or confidential, uses Authorization Code with PKCE, and Implicit Grant, along with the Resource Owner Password Credentials grant and bearer tokens in query strings, is removed rather than merely deprecated.

Do not start reconfiguring the identity provider or shipping client updates before these are in place. Skipping the inventory step is the single most common cause of an incomplete or broken rollout.

Run these steps in this order, one client at a time if you have more than a handful. Do not skip ahead to disabling Implicit Grant before the client-side steps have reached full rollout for that client, that ordering mistake is covered in the failure cases section below.

The runbook above applies to every client type, but the details differ enough to call out separately. Single-page applications are public clients with no client secret, so PKCE is doing the entire job of proving the token exchange request came from the same client that started the authorization request. Use the S256 code challenge method, keep the code_verifier in memory rather than in storage that persists across page loads unless you also handle the redirect-and-reload case carefully, and confirm your OAuth library actually supports PKCE for SPAs specifically, since some older SDK versions built for Implicit Grant do not add PKCE support automatically on upgrade. Mobile apps have their own wrinkle: the authorization request needs to happen in a system browser component, such as ASWebAuthenticationSession on iOS or Chrome Custom Tabs on Android, rather than an embedded webview, since an embedded webview can be manipulated by the host app to intercept the code, undermining part of what PKCE is meant to prevent. Confirm the redirect URI scheme is registered exactly as the mobile OS expects, since custom URI schemes are also subject to the exact-match requirement. Server-side, confidential clients that were already using Authorization Code do not need to change their flow, but OAuth 2.1 still expects PKCE added to these too, since a client secret protects the token exchange step but does not protect the authorization code itself from interception in transit.

Do not consider a client migrated because the code deployed without errors. Confirm each of the following before removing Implicit Grant for that client, and again after.

Every failure mode below traces back to a step being run out of order relative to the runbook above, not to PKCE or Authorization Code being inherently fragile.

PKCE closes a specific gap: it prevents a stolen or intercepted authorization code from being exchanged for tokens by a party that does not hold the original code_verifier. It does not, by itself, protect a token that has already been issued and stored insecurely, which is why token storage is called out as its own step in the runbook rather than treated as a side effect of the PKCE change. A SPA that migrates to Authorization Code with PKCE but still stores the resulting access token in localStorage has closed the code-interception gap while leaving an XSS-driven token theft gap wide open. PKCE also does not replace the value of short-lived access tokens, refresh token rotation, or sender-constrained tokens (DPoP or mutual TLS) for genuinely high-value clients; treat OAuth 2.1 compliance as the floor for a modern OAuth deployment, not the ceiling. Teams running this migration alongside a broader identity hardening push often have Entra ID legacy authentication protocols in scope at the same time; see our guide on blocking legacy authentication in Microsoft 365 and Entra ID if that is also on your list, since both efforts touch the same client registrations and both fail the same way when rolled out to every user at once instead of staged. If MFA policy is part of the same identity modernization effort, our Cisco Duo vs Okta MFA comparison covers how the two handle step-up authentication and conditional access, which is a separate but related decision from the OAuth flow itself.