Back to Grant Types
DeprecatedID: implicit

Implicit Flow

A legacy browser flow where access tokens were returned directly in the URL hash fragment. Deprecated due to token leakage vulnerabilities; use Authorization Code with PKCE instead.

#oauth2#implicit#deprecated#legacy#security-risk#spa
Security Notice: Deprecated Flow

Implicit Flow is formally deprecated in modern OAuth specifications (including OAuth 2.0 Security BCP and OAuth 2.1). It poses significant security risks and must NOT be used for new applications. Use Authorization Code Flow with PKCE instead.

Overview

The Implicit Grant (RFC 6749 Section 4.2) was created in 2012 when browser-based JavaScript applications could not make cross-origin HTTP requests (prior to wide CORS adoption).

In this flow, the authorization server returned the access token directly in the URI hash fragment (#access_token=...) of the redirect URL without an authorization code exchange or client authentication.

Why it is deprecated: Exposing tokens in URL hash fragments makes them vulnerable to browser history logging, Referrer header leakage, server log exposure, and malicious browser extensions. Furthermore, the flow lacks client authentication and cannot issue refresh tokens.

The OAuth 2.0 Security Best Current Practice and OAuth 2.1 have formally deprecated the Implicit Grant. Modern applications MUST use Authorization Code Flow with PKCE.

Quick Specifications

Flow Status
deprecated
Token Auth Methods
None
Primary Standard
RFC 6749 Section 4.2

Sequence Diagram

Visual sequence illustrating entity interactions and protocol steps

Sequence Diagram
Interactive Diagram
sequenceDiagram
    autonumber
    actor U as User
    participant B as Browser (SPA)
    participant AS as Authorization Server

    U->>B: Click "Log In"
    B->>AS: GET /authorize (response_type=token, client_id, redirect_uri, scope, state)
    AS->>U: Display Login & Consent Prompt
    U->>AS: Submit Credentials
    AS-->>B: 302 Redirect to callback#access_token=AT_XYZ&token_type=bearer&expires_in=3600
    Note over B: Security Risk: Token exposed in URL fragment & browser history!
    B->>B: Parse access_token from window.location.hash
    B->>U: Display Authenticated UI

Step-by-Step Flow Breakdown

Detailed breakdown of every message exchange, query parameter, and HTTP payload

1

Initiate Login

User→Browser (SPA)

The user clicks the login button in the client-side Single Page Application.

2

Request with response_type=token

Browser (SPA)→Authorization Server

The SPA redirects the browser to the authorization endpoint requesting response_type=token.

Implicit Authorization Request
GET /authorize?
    response_type=token
    &client_id=legacy_spa_client
    &redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback
    &scope=read%20write
    &state=af0ifjsldkj HTTP/1.1
Host: auth.example.com
3

User Authenticates

Authorization Server→User

The user enters their credentials at the authorization server.

4

Token Returned in URL Fragment

Authorization Server→Browser (SPA)

The authorization server redirects back with the access token placed in the URI fragment after the hash (#) character.

Redirect with Token in Fragment
HTTP/1.1 302 Found
Location: https://myapp.com/callback#access_token=2YotnFZFEjr1zCsicMWpAA&token_type=Bearer&expires_in=3600&state=af0ifjsldkj
5

Extract Token from Hash

Browser (SPA)→Browser (SPA)

The client application reads the token from window.location.hash using JavaScript.

Fragile Fragment Parsing
// Token extraction from window.location.hash
const hash = window.location.hash.substring(1);
const params = new URLSearchParams(hash);
const accessToken = params.get('access_token');

Security Considerations

Critical safeguards, threat mitigations, and implementation best practices

DEPRECATED: Do Not Use in New Projects

The Implicit Flow has been removed in OAuth 2.1 and is strongly discouraged by the IETF OAuth working group. Migrate to Authorization Code with PKCE.

Token Leakage via URL Fragment

URI fragments are stored in browser history, visible in browser address bars, and accessible to third-party scripts and extensions injected into the DOM.

No Sender Verification or Client Authentication

Because there is no back-channel exchange, anyone possessing the token can present it. There is no cryptographic binding to the client.

Specifications & Standards

Official IETF RFCs and OpenID Foundation standards defining this flow

Other OAuth 2.0 Grant Types

Compare with other authentication and authorization flows