What was the point of Implicit Grant Flow in OAuth 2.0?

Question

I've read a lot about Implicit Grant Flow and when it should be used, but I can't wrap my head around a use case for where it would have made sense over the Authentication Code Grant Flow before PKCEs were a recommended option.

Here is what I know so far:

1. Implicit Grant Flow is less secure than Authentication Code Grant Flow; and thus, Authentication Code Grant Flow should be preferred over Implicit Grant Flow unless some particular use case has no other option but Implicit Grant Flow.
2. A JavaScript single-page application that is downloaded from S3 would have no way to complete the last leg of the Authentication Code Grant Flow because (1) it can't create an API for handling this on the S3 server from which it was downloaded, (2) it wouldn't be able to make cross-origin requests, and (3) it can't store a client side secret in the app.

So, if a hypothetical JavaScript SPA that is downloaded from S3 wanted to authenticate a user via Gmail, then it would have to use the Implicit Grant Flow. But if this SPA has no real backend of its own, then why would it ever need to authenticate a user? Is it maybe because this hypothetical S3 SPA has a CORS policy that allows it to access cross-origin APIs? Is this possible in S3? This sounds like a reasonable use case, but one that I'm not personally familiar with - thus, is this something that people are using out in the wild? And are there any notable examples of this?

Finally, if you're SPA does have a backend of its own, then wouldn't the Authentication Code Grant Flow be the recommended grant flow because it is more secure and it can be feasibly implemented given that you own the backend?

---

P.S. I'm asking what was the point because my understanding is that any use cases that required Implicit Grant Flow should now use Authentication Code Grant Flow with PKCEs.

Answer 1

The already mentioned advantages in responsiveness and simpleness for some clients (trade-offs in security are also mentioned in the spec):

The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. […]

[…]

Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of using implicit grants, such as those described in Sections 10.3 and 10.16, especially when the authorization code grant type is available.

(RFC 6749, Section 1.3.2)

The other reason why the implicit flow was simply needed is due to restrictions in the technology (CORS was not implemented) back in 2012:

The Implicit flow in OAuth 2.0 was created nearly 10 years ago, when browsers worked very differently than they do today. The primary reason the Implicit flow was created was because of an old limitation in browsers. It used to be the case that JavaScript could only make requests to the same server that the page was loaded from. However, the standard OAuth Authorization Code flow requires that a POST request is made to the OAuth server’s token endpoint, which is often on a different domain than the app. That meant there was previously no way to use this flow from JavaScript. The Implicit flow worked around this limitation by avoiding that POST request, and instead returning the access token immediately in the redirect.

Today, Cross-Origin Resource Sharing (CORS) is universally adopted by browsers, removing the need for this compromise. CORS provides a way for JavaScript to make requests to servers on a different domain as long as the destination allows it. This opens up the possibility of using the Authorization Code flow in JavaScript.

It’s worth noting that the Implicit flow has always been seen as a compromise compared to the Authorization Code flow. For example, the spec provides no mechanism to return a refresh token in the Implicit flow, as it was seen as too insecure to allow that. The spec also recommends short lifetimes and limited scope for access tokens issued via the Implicit flow.

(okta Developer: Is the OAuth 2.0 Implicit Flow Dead?, Section The OAuth Authorization Code Flow is Better)

Answer 2

Fortunately, I work at Ping Identity where some of the people who wrote the OAuth 2.0 and OIDC spec work! I had a recent conversation about this very topic because we were chatting about the new RFC that is basically recommending people not use the implicit flow anymore.[1]

Your confusion is likely because it wasn't created for a different use case but for simplicity. This is from conversations and the original spec which states (with my emphasis):

The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript.

It's a simplified flow of the one you should be using (authorization code) for simple apps.

This simplicity also helps a little for efficiency:

Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token.

The main purpose though was simplicity in design. With the announcement of a new security standard for identity, they wanted to provide a simple option for greater adoption. With a simpler method, it would be easier to implement and less time-consuming.

[https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13#page-6][1]