OAuth 2.0 Implicit Flow to Authorization Code Flow with PKCE Transition

Question

A small-scale application is upgrading its authentication mechanism to align with OAuth 2.1 standards by migrating from the deprecated Implicit Flow to the Authorization Code Flow with PKCE. The goal is to eliminate the exposure of access tokens in the URL fragment without introducing service downtime.

The proposed strategy involves configuring the Authorization Server to support both response_type=token and response_type=code for the same client ID during a transition window. This allows existing clients to function while new versions are deployed.

Uncertainty exists regarding the token lifecycle management during this shift, specifically when introducing refresh tokens to a client that previously relied on short-lived implicit tokens.

Should the application maintain the existing short-lived access token duration or implement a new expiration strategy alongside refresh tokens?
  What is the recommended approach for handling session persistence for users who authenticated via the Implicit Flow just before the PKCE transition?

Tasadduq Burney · Answer

Answer
The likely explanation is that the transition can be performed without downtime by supporting both flow types temporarily and introducing refresh tokens for robust token lifecycle management.
Confirmed steps

Configure the Authorization Server to accept both response_type=token and response_type=code for the same client ID during the transition window.
Update the client to use the Authorization Code grant with PKCE, issuing a short‑lived access token (e.g., 5–15 minutes) and a refresh token.
Maintain the existing short‑lived access token duration only if the server enforces it; otherwise adopt a new expiration strategy that aligns with refresh token usage.
Persist user sessions server‑side (session ID or JWT) and map the legacy Implicit session to the new code grant by re‑issuing a code for the same user or using a session‑linking endpoint.
Validate that the Authorization Server supports the token endpoint with the refresh_token grant and that the client can exchange the refresh token for new access tokens without exposing them in the URL fragment.

OAuth 2.0 Implicit Flow to Authorization Code Flow with PKCE Transition

1 answer

Answer

Confirmed steps

Your perspective belongs here.

0 question comments