What is the difference between implicit flow and authorization code flow with PKCE?

How the two flows differ in how the browser receives tokens

Implicit flow delivers tokens straight to the browser, so the browser becomes part of the token delivery path. That was convenient for older single-page app patterns, but it also widened exposure to accidental disclosure through browser history, logs, referrer handling, and client-side scripts. Authorization code flow changes that trust model by moving token delivery behind a separate exchange.

With authorization code flow, the browser receives only a short-lived authorization code first, then the client exchanges that code for tokens. That extra step means the sensitive tokens do not need to travel through the browser redirect in the same way, which is one of the main reasons modern guidance has moved away from implicit flow for most apps.

Why PKCE changes the security properties of the code flow

PKCE adds a verifier and challenge so the authorization code is bound to the client that started the flow. In practice, that makes intercepted codes far less useful because a stolen code alone is not enough to complete the exchange. For modern public clients, this closes the gap that earlier made browser-based flows easier to abuse.

The important distinction is that PKCE does not merely add another parameter. It changes the threat model by reducing the value of code interception, especially in environments where an attacker might see redirect traffic, browser events, or an intermediate authorization response. For current OAuth 2.0 deployments, that is why authorization code flow with PKCE is the safer default, and the browser guidance in OAuth for Native and Mobile Apps Guide aligns with that shift.

Which flow to use today, and when the old pattern still matters

For modern browser apps, authorization code flow with PKCE is generally the right choice because it gives you a cleaner separation between front-channel interaction and token issuance. It is also easier to align with secure redirect handling, modern OAuth best current practice, and safer client types. The broader migration away from implicit flow is captured in OAuth 2.0 Security Best Current Practice Guide, which focuses on token theft, code injection, and PKCE downgrade risk.

Implicit flow only remains relevant when you are supporting older integrations or inherited browser patterns that have not yet been refactored. Even then, the practical question is whether the old behavior is still justified by compatibility alone. In most cases, the safer path is to preserve the user experience while changing the underlying flow, not to keep the legacy token-return pattern.

Risk and Threat Considerations

Implicit flow concentrates risk in the browser because tokens are exposed earlier and more broadly in the client runtime. Authorization code flow with PKCE reduces that exposure, but only if redirect handling, client registration, and code exchange are implemented correctly.

Failure mechanism: An attacker who can intercept a front-channel response, abuse a weak redirect URI, or steal browser-resident tokens can often reuse what they capture directly in implicit flow. With PKCE, a stolen authorization code is much less useful unless the attacker can also satisfy the verifier binding.

Impact: Token leakage can lead to account takeover, API abuse, and persistent access until the affected tokens are revoked or expire. If the code flow is deployed without PKCE or with weak redirect controls, the security gain over implicit flow is sharply reduced.

Practitioner Guidance

What to verify: Confirm that your browser-based client uses authorization code flow with PKCE end to end, not a hybrid implementation that still exposes tokens in the front channel. Verify that redirect URIs are exact, that the code verifier is generated per login, and that the application never logs authorization responses.

Decision rule: If the client is public, browser-based, or unable to keep a client secret safely, treat PKCE as mandatory rather than optional. If you still have implicit flow in production, treat it as a migration item, not a design preference.

Practitioner takeaway: The key difference is not just “code versus token”, it is where trust is placed. Authorization code flow with PKCE narrows the browser’s exposure and makes interception materially harder, which is why it is now the default pattern for modern apps.

Related resources from NHI Mgmt Group

• Guide: OAuth 2.0 and OpenID Connect Guide for Identity Teams
• How do organisations decide whether to move from implicit flow to authorization code flow in web applications?
• How should security teams implement the OAuth authorization code flow safely?
• How do organisations decide between OAuth Authorization Code flow and Client Credentials?
• What is the difference between Authorization Code with PKCE and Client Credentials for AI agents?