What is the difference between Authorization Code and Implicit grant types in OAuth?

Why the Two Grant Types Behave So Differently

The practical difference is not just where the token appears, but where trust is established. Authorization Code uses a back-channel exchange that keeps the access token away from the browser, which reduces exposure to redirect interception, browser history leakage, and token reuse by injected script. Implicit returns the token directly in the redirect response, so the browser becomes part of the sensitive token path.

That design difference changes the security model. Authorization Code supports stronger client validation, tighter token handling, and cleaner separation between the user-facing redirect and the token issuance step. Implicit was originally attractive for simple browser apps, but modern guidance has moved away from it because the browser-delivered token is harder to protect once it is issued.

In practice, many teams only discover the weakness of browser-delivered tokens after an integration has already been exposed to leakage or replay.

For a broader view of how OAuth token handling intersects with identity governance and token lifecycle risk, Ultimate Guide to NHIs is a useful reference.

How It Works in Practice

Authorization Code follows a two-step pattern. The browser is redirected back with a short-lived code, then the client exchanges that code with the authorization server to obtain tokens. Because the token exchange happens server to server, the access token can remain out of the browser for confidential clients, and the client can authenticate itself during the exchange.

Implicit collapses those steps. After user approval, the access token is returned immediately in the browser redirect, which avoids a back-channel exchange but also increases exposure to interception, logging, and client-side mishandling. That is why it was once common in single-page applications, especially before more secure browser-based patterns were widely adopted.

• Authorization Code is better when the client can keep secrets or use a secure token exchange path.
• Implicit is weaker because the browser receives the token directly and must treat it as highly exposed.
• The core trade-off is simplicity versus token protection, not just developer convenience.

Modern deployments often pair Authorization Code with PKCE for public clients, which preserves the safer exchange pattern without requiring a client secret. That makes the older Implicit flow unnecessary in most cases. These controls tend to break down when applications store tokens in insecure browser locations or when redirect handling is shared across poorly isolated front-end components.

Common Variations and Edge Cases

Tighter token handling often increases implementation complexity, requiring organisations to balance browser simplicity against stronger client assurance. The main edge case is the public client, where the application cannot safely hold a long-term secret. In that case, Authorization Code with PKCE is generally preferred because it keeps the browser out of the token issuance step while still supporting modern front-end architectures.

Another nuance is that “simple” does not mean “safe enough.” Some older single-page application designs used Implicit because it reduced friction, but current guidance suggests that the browser exposure created more risk than convenience. If an implementation still depends on Implicit, the control gap usually shows up in token leakage, weak refresh handling, or inconsistent session invalidation.

Teams should also separate oauth grant choice from the broader question of access policy. A safer grant type does not fix overbroad scopes, weak redirect URI control, or poor token storage. The grant flow is only one part of the trust boundary, and it works best when the surrounding authorization rules are equally strict. In environments with multiple front ends, the risk increases when one redirect pattern is reused without consistent client validation.

Risk and Threat Considerations

The security concern with Implicit is token exposure in a browser-mediated path, which expands the set of places where an access token can leak or be reused. That creates a materially larger attack surface than a back-channel exchange, especially in applications with complex front-end code, shared browsers, or weak redirect handling.

Failure mechanism: If an access token is issued directly to the browser, it can be captured through redirect manipulation, browser compromise, logging, injected script, or unsafe client-side storage. An attacker who obtains the token may be able to replay it until it expires or use it to access protected APIs within the granted scope.

Impact: Stolen tokens can expose user data, enable unauthorized API access, and undermine confidence in the session boundary. In multi-application environments, the blast radius is larger when the same browser session or token handling pattern is reused across systems.

Practitioner Guidance

What to prioritise: Prefer Authorization Code for new work, and treat Implicit as legacy unless there is a very constrained reason it still exists. The decisive question is whether the client can complete a secure token exchange without exposing the token to the browser.

What to verify: Check whether redirect URIs are tightly controlled, whether the client is public or confidential, and whether the implementation uses PKCE where appropriate. Also verify where tokens are stored after receipt, because browser storage choices can erase the security benefit of a better grant type.

Common mistake: Teams sometimes assume that because the user login step is the same, the grant types are equivalent. They are not, because the token delivery path determines whether the browser becomes part of the trust boundary.

Practitioner takeaway: If the browser can see the access token, the design should be treated as higher exposure by default, and the rest of the architecture must justify that choice.

Related resources from NHI Mgmt Group

• What is the difference between an authorization code and an access token in OAuth?
• What is the difference between implicit flow and authorization code flow with PKCE?
• What is the difference between the authorization code and the refresh token in OAuth 2.0?
• What is the difference between enforcing authorization in the gateway and in application code?