โฟลว์แบบแฝงและการเลิกใช้งาน

Welcome to a look at the Implicit Flow, an older OAuth2 authorization grant type. It was once popular for certain types of applications but is now largely deprecated due to security concerns.

It's important to understand its mechanics to grasp why more secure alternatives are now preferred.

Unlike other flows that exchange an authorization code for a token, the Implicit Flow delivers the access token directly to the client.

This happens immediately after the user grants authorization, without an intermediate step or server-side interaction to retrieve the token.

The Implicit Flow involves fewer steps than the Authorization Code Flow:

• The client redirects the user's browser to the Authorization Server.
• The user authenticates and grants permission.
• The Authorization Server redirects the user's browser back to the client, embedding the access token directly in the URL fragment.
• The client-side script extracts the token from the URL.

The key characteristic is the token's location. It's appended to the redirect URL as a fragment identifier (after a # symbol).

This means the token is handled entirely by the browser and is never sent to the client's web server, which was seen as a security feature for public clients.

The Implicit Flow was primarily designed for public clients. These are applications that cannot securely hold a client secret, such as:

• Single-Page Applications (SPAs) running in a browser
• Native mobile applications

Without a backend server to exchange an authorization code, direct token delivery seemed simpler.

One major drawback is that the access token appears in the browser's URL. This makes it vulnerable to:

• Browser History: Stored in the user's browser history.
• Referrer Headers: Potentially leaked to third-party sites via referrer headers.
• Server Logs: If the URL is logged by a proxy or server, the token can be exposed.

This is a significant security risk!

With the Implicit Flow, the client application itself does not authenticate with the Authorization Server.

This means the Authorization Server cannot verify the identity of the client requesting the token, which can lead to vulnerabilities like:

• Unauthorized clients impersonating legitimate ones.
• Difficulty in revoking access for specific compromised clients.

The Implicit Flow is more susceptible to Cross-Site Request Forgery (CSRF) attacks without proper mitigation.

An attacker could trick a user into authorizing an application they didn't intend to, and the access token would be delivered directly to the attacker's controlled redirect URI.

While the state parameter helps, the direct token delivery increases the attack surface.

Due to these inherent security flaws, the OAuth 2.0 Security Best Current Practice document recommends against using the Implicit Flow.

It's being replaced by more robust and secure alternatives, primarily the Authorization Code Flow with PKCE (Proof Key for Code Exchange).

PKCE specifically addresses the public client problem by adding a layer of cryptographic protection.

You've learned that the Implicit Flow was an OAuth2 grant type for public clients, delivering access tokens directly in the URL fragment.

However, its simplicity came at the cost of significant security risks, primarily token exposure and lack of client authentication.

Modern best practices strongly recommend using the Authorization Code Flow with PKCE as a secure alternative for public clients.