Implicit Grant (Deprecated)

How it works

The Implicit grant was a shortcut for browser apps that could not store a client_secret. Instead of returning an authorization code, the authorization server returned the access_token directly in the URL fragment (#access_token=...).

Why it was problematic: - Access token exposed in URL fragment → browser history, server logs, Referer headers - No refresh token → user must re-authorize frequently - Access token in JavaScript memory → XSS attacks can steal tokens - No binding between token and client → token theft and replay attacks

Deprecation timeline: - OAuth 2.0 Security BCP (draft-ietf-oauth-security-topics) recommends against implicit - OAuth 2.1 (draft) formally removes implicit grant - All major IdPs (Auth0, Okta, Azure AD, Google) recommend PKCE instead

Migration: replace implicit grant with Authorization Code + PKCE. The user experience is identical (redirect-based). The security is dramatically better.

Legacy code: if you maintain an existing implicit grant implementation, migrate to PKCE. The changes are minimal: add code_verifier/code_challenge generation and change response_type=token to response_type=code.

Flow Steps

1. 1

   DEPRECATED – do not implement in new applications

2. 2

   Redirect to /authorize?response_type=token (returns token in URL fragment)

3. 3

   Token is exposed in browser history and logs

4. 4

   Use Authorization Code + PKCE instead

Parameters

Examples

# ❌ DEPRECATED – implicit grant (DO NOT USE)
GET /authorize?response_type=token&client_id=spa
# Returns: /callback#access_token=abc&expires_in=3600
# Token is in URL fragment – exposed in history, logs, Referer

# ✅ CORRECT – Authorization Code + PKCE
GET /authorize?response_type=code
  &client_id=spa
  &code_challenge=...
  &code_challenge_method=S256
# Returns: /callback?code=abc  (no token in URL)