Skip to main content
Identity Authority
Category: OAuth & OIDC

Implicit Grant

Also known as: Implicit Flow
Simply put

Implicit Grant is an older way for a web application to obtain access to a user's resources through OAuth 2.0, in which the token is returned directly to the application running in the browser without a separate exchange step. It was designed for browser-based apps that could not securely keep a secret. It is now generally discouraged in favor of more secure approaches, though exact guidance depends on the standard profile and deployment context.

Formal definition

The Implicit Grant is one of the authorization grant types defined in the OAuth 2.0 framework, intended historically for public clients such as single-page or browser-based applications that cannot protect a client secret. In this flow the authorization server returns an access token directly to the client via the redirect URI (typically in the URL fragment) in a single front-channel step, without the intermediate authorization code exchange used by the authorization code grant. Because the token is exposed in the front channel and this flow does not support refresh tokens or client authentication, it carries security limitations; in most current guidance the authorization code grant with PKCE is recommended instead for browser-based clients. As an OAuth 2.0 mechanism, the Implicit Grant concerns delegated authorization and token issuance, not user authentication; authenticating end users requires an authentication layer such as OpenID Connect. Exact behavior, supported response types, and whether the grant is available at all vary by authorization server, OAuth profile, and configuration.

Why it matters

The Implicit Grant matters primarily because it represents a security posture that the IAM community has moved away from, and understanding why is essential for anyone maintaining or migrating browser-based applications. In this flow the access token is returned directly through the front channel, typically in the URL fragment, where it is more exposed to interception, leakage through browser history or referrer headers, and injection risks than a token obtained through a back-channel exchange. Because the flow does not support client authentication and typically does not issue refresh tokens, it also offers fewer options for limiting the blast radius of a compromised token.

For security architects and IAM engineers, the practical significance is that many existing single-page and browser-based applications were built on the Implicit Grant during a period when it was the recommended pattern for public clients. Current guidance for browser-based clients generally favors the authorization code grant with PKCE instead, which means teams frequently encounter Implicit Grant usage as technical debt to be assessed and migrated. Recognizing the flow's limitations helps prioritize that remediation work.

It is also important to keep scope precise: the Implicit Grant is an OAuth 2.0 authorization mechanism concerned with delegated authorization and token issuance, not with authenticating end users. Treating a token obtained through this flow as proof of user identity is a category error; authenticating users requires an authentication layer such as OpenID Connect. Whether the Implicit Grant is even available depends on the authorization server, OAuth profile, and configuration, so its relevance in a given environment must be verified rather than assumed.

Who it's relevant to

Security Architects
Architects evaluating how browser-based applications obtain tokens need to identify where the Implicit Grant is in use and weigh its front-channel token exposure and lack of client authentication against alternatives. In most current guidance the authorization code grant with PKCE is preferred for browser-based clients, and architects typically define the target pattern and migration approach accordingly.
IAM Engineers and Developers
Engineers maintaining single-page or browser-based applications may inherit Implicit Grant implementations and must understand that these flows return the access token directly in the redirect URI and generally do not support refresh tokens. This shapes how they handle token lifetime, storage, and the work involved in migrating to a code-plus-PKCE flow, depending on what the authorization server supports.
Compliance and Audit Leads
Those reviewing access architectures should recognize the Implicit Grant as a pattern that is generally discouraged in favor of more secure approaches, while noting that exact guidance depends on the standard profile and deployment context. Its presence is a reasonable item to flag for review, and reviewers should confirm that a token obtained via this OAuth 2.0 flow is not being misused as evidence of user authentication.

Inside Implicit Grant

Response Type token/id_token
The Implicit Grant is invoked in OAuth 2.0 using response_type=token (for an access token) or, in OpenID Connect, response_type=id_token or id_token token. The requested credentials are returned directly from the authorization endpoint without a separate token endpoint exchange.
Front-channel token delivery
Tokens are returned to the client via the browser redirect, typically in the URI fragment (after the # symbol). This front-channel delivery is the defining characteristic that distinguishes Implicit from the Authorization Code grant, which delivers a code over the front channel and tokens over the back channel.
Absence of client authentication
The Implicit Grant was designed for public clients such as browser-based single-page applications that cannot securely hold a client secret. In most implementations no client authentication occurs at the authorization endpoint for this flow.
No refresh token
Under the OAuth 2.0 specification, refresh tokens are typically not issued via the Implicit Grant. Clients generally must re-run the flow or use a silent re-authentication technique to obtain new tokens, depending on the authorization server's configuration.
Deprecation status
The Implicit Grant is discouraged in current OAuth security guidance in favor of the Authorization Code flow with PKCE for public clients. Its use is now considered a legacy pattern in most deployments.

Common questions

Answers to the questions practitioners most commonly ask about Implicit Grant.

Does the Implicit Grant authenticate users?
No. The Implicit Grant is a flow within the OAuth 2.0 delegated authorization framework, and OAuth 2.0 by itself is not an authentication protocol. The Implicit Grant was designed to obtain an access token for authorizing access to resources, not to prove who the user is. If you need to authenticate a user, you should use OpenID Connect, the authentication layer built on top of OAuth 2.0, which defines an ID token for conveying authentication information. Using an access token as if it were proof of authentication is a common and dangerous mistake.
Is the Implicit Grant just a faster or simpler version of the Authorization Code Grant that is otherwise equivalent?
Not equivalent. While the Implicit Grant was historically favored for browser-based clients because it returned the access token directly from the authorization endpoint without a separate token exchange, this design has meaningful security trade-offs. The token is exposed in the redirect (typically in the URL fragment) and there is no back-channel token exchange. The Authorization Code Grant, particularly when combined with PKCE, addresses several of these exposures. Current guidance in the broader OAuth community has moved away from the Implicit Grant for these reasons, so it should not be treated as a benign shortcut.
What should I use instead of the Implicit Grant for a single-page application?
In most current deployments, the recommended approach for single-page applications is the Authorization Code Grant with PKCE (Proof Key for Code Exchange), which is designed to protect public clients that cannot securely hold a secret. This lets a browser-based client obtain an authorization code and exchange it for tokens while mitigating code interception. The exact behavior and supported flows depend on your authorization server and its configured profile, so confirm PKCE support with your provider.
Where does the token appear when the Implicit Grant is used, and why does that matter?
In the Implicit Grant, the access token is typically returned directly in the redirect URI, commonly in the URL fragment. This matters because tokens placed in URLs can be exposed through browser history, referrer headers, logs, and access by scripts running in the page. These exposure paths are a primary reason the flow is discouraged. Handling and clearing the fragment carefully is required in any legacy deployment that still relies on it, though depending on configuration these mitigations may be incomplete.
Can the Implicit Grant issue refresh tokens?
As originally specified, the Implicit Grant did not provide for issuing refresh tokens, in part because of the token exposure characteristics of the flow. Clients using it typically had to obtain new tokens by repeating the authorization request. Behavior can vary by vendor and profile, so verify against your specific authorization server, but you should not assume refresh token support with this grant.
If I still have systems using the Implicit Grant, what should I check during migration?
Confirm whether your authorization server supports the Authorization Code Grant with PKCE as a replacement, inventory clients that currently rely on the Implicit Grant, and review how each client consumes and validates tokens. Verify that any client mistakenly using an access token for authentication is redesigned to use OpenID Connect ID tokens where user authentication is actually required. Migration steps and available options depend on your provider and deployment context, so validate each assumption against your environment rather than assuming a uniform path.

Common misconceptions

The Implicit Grant authenticates users.
OAuth 2.0, including the Implicit Grant, is a delegated authorization framework, not an authentication protocol. User authentication in this context comes from OpenID Connect (built on top of OAuth 2.0) via an id_token; the OAuth Implicit Grant itself concerns obtaining an access token for authorization, not verifying user identity.
The Implicit Grant is the correct choice for single-page applications because they cannot keep a secret.
While the Implicit Grant was originally intended for public browser-based clients, current OAuth security guidance recommends the Authorization Code flow with PKCE for such clients instead. The Implicit Grant is now generally treated as a legacy option rather than the preferred approach.
Tokens delivered by the Implicit Grant are protected because they are returned over HTTPS.
Transport encryption protects data in transit, but Implicit returns tokens in the URL fragment where they are exposed to browser history, referrer leakage, and script access on the page. A signed token is not the same as an encrypted or otherwise confidential one, and front-channel delivery introduces exposure risks that the back-channel Authorization Code exchange avoids.

Best practices

Prefer the Authorization Code flow with PKCE over the Implicit Grant for public clients such as single-page applications, in line with current OAuth security guidance.
If migrating away from an existing Implicit Grant deployment, inventory all clients relying on response_type=token or id_token token before changing authorization server configuration.
Do not rely on the Implicit Grant for authentication; use OpenID Connect and validate the id_token's signature and claims when user identity is required.
Where the Implicit Grant must remain in use, minimize token lifetimes and treat front-channel-delivered tokens as exposed, clearing them from the URL fragment after processing.
Do not expect refresh tokens from the Implicit Grant; plan for silent re-authentication or full re-authorization depending on your authorization server's supported behavior.
Confirm your authorization server's supported response types and profile rather than assuming behavior, since token issuance and grant availability vary by vendor and configuration.
Promotional banner for the Pentest Readiness checklist download