English

oauth
implicit flow
authorization code flow
PKCE

Implicit flow vs. Authorization code flow: Why implicit flow is dead?

Why is there an "Authorization code flow" in OAuth 2.0 when we already have the "Implicit flow"? Let's dive into the details of these two grant types and find out why you should avoid using the implicit flow.

Darcy Ye

Developer

1/3/20246 min read

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

The Authorization code flow and Implicit flow are two of the most commonly used grant types in OAuth 2.0, enabling secure and efficient user authorization for web applications. Both flows implement an authorization process that allows users to grant access to applications without exposing their credentials directly. The Implicit flow was initially developed to address browser limitations, but with the advent of modern web technologies, the Authorization code flow has become the preferred choice for many developers due to its enhanced security features.

In this article, we'll explore the differences between these two grant types and explain why you should avoid using the Implicit flow in favor of the Authorization code flow.

What is OAuth 2.0?

Before we dive into the details of these two grant types, let's first understand what OAuth 2.0 is and why it's essential for modern web applications.

When people talk about OAuth, we usually refer to OAuth 2.0, known as "Open Authorization", is an established protocol enabling websites or applications to utilize resources from other web services on a user's behalf. It succeeded OAuth 1.0 in 2012 and has since become the widely accepted standard for digital authorization. OAuth 2.0 is designed to provide controlled access to users, allowing client applications specific permissions to interact with resources representing the user, all without revealing the user's login details.

Although primarily utilized in web environments, OAuth 2.0's framework also extends to various client forms. This includes browser-based apps, server-side web applications, native or mobile applications, and even interconnected devices, detailing the approach for managing delegated access across these platforms. It introduces the concept of "grant types" to define the authorization process between the client application, the user, and the authorization server. These grant types are used to determine how the client application can obtain an access token to access the user's resources. The most common grant types in OAuth 2.0 are:

Authorization code: Ideal for all types of applications, especially server-side web applications, where the client application can exchange an authorization code for an access token and manage tokens securely.
Implicit: A simplified flow, designed for browser-based applications, without a secure server component. It was created to quickly deliver tokens to the client applications. But it is now largely deprecated due to security concerns.
Resource owner password credentials: This type allows the client application to directly request and receive an access token by submitting the user's credentials (username and password). Due to the fact that the client application has a direct access to the user's credentials, this grant type is also considered as deprecated and should be avoided in all circumstances.
Client credentials: Used for machine-to-machine communication where the application itself is the client. It involves the application authenticating with the authorization server and requesting an access token to access its own resources or those of another service.

What is the implicit flow?

The implicit flow is a simplified OAuth 2.0 flow where the access token is returned directly to the client in the redirect URI, without an additional step to exchange an authorization code for a token. It was originally designed for web applications that couldn't make server-side requests to the token endpoint due to browser restrictions.

How implicit flow works?

The user clicks a button or link on the client application to initiate the authentication process.
The client application redirects the user to the authorization server to authenticate, including the desired scope of access.
The authorization server prompts the users to log in and grant permission to the client application.
Upon successful authentication and authorization, the authorization server redirects the user's browser back to the client's specified redirect URI, with the access token included in the URL fragment.
The client application extracts the access token from the URL fragment and uses it to access the user's resources on the resource server.

Security risks with implicit flow

The implicit flow has several security vulnerabilities:

Token exposure: The access token is returned directly to the client in the URL fragment, which can be easily intercepted by malicious parties. This exposes the access token to potential theft and misuse.
CSRF attacks: The implicit flow is susceptible to Cross-Site Request Forgery (CSRF) attacks, where malicious websites can trick users into granting unauthorized access to their accounts.

Due to these security concerns, the implicit flow is no longer recommended for modern web applications. Instead, the authorization code flow with PKCE (Proof Key for Code Exchange) is the preferred choice for secure user authorization.

What is the authorization code flow?

The authorization code flow, on the other hand, is a more secure OAuth 2.0 flow that separates the authorization process into two steps: the client application first obtains an authorization code from the authorization server, then exchanges the code for an access token. This flow was initially designed for server-side web applications that can securely store client credentials and manage access tokens. With the introduction of the PKCE extension, the authorization code flow can now be used in browser-based applications as well.

How authorization code flow works for private clients with server-side component?

The user clicks a button or link on the client application to initiate the authentication process.
The client application redirects the user to the authorization server to authenticate with the desired scope of access.
The authorization server prompts the users to log in and grant permission to the client application.
Upon successful authentication and authorization, the authorization server returns an authorization code to the client.
The client application securely exchanges the authorization code for an access token by making a server-to-server request to the token endpoint using its client credentials.
The authorization server validates the authorization code and client credentials and returns an access token to the client.
The client application uses the access token to access the user's resources on the resource server.

How authorization code flow works for public clients with PKCE?

The user clicks a button or link on the client application to initiate the authentication process.
The client application generates a code verifier and a code challenge.
The client application redirects the user to the authorization server to authenticate with the code challenge.
The authorization server stores the code challenge for later verification.
The user authenticates and approves access to the client application.
The authorization server returns an authorization code to the client.
The client application exchanges the authorization code for an access token by making a server-to-server request to the token endpoint using the code verifier.
The authorization server validates the authorization code and code verifier against the stored code challenge.
The authorization server returns an access token to the client.
The client application uses the access token to access the user's resources on the resource server.

Learn more about the PKCE flow.