0

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.

1

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://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#page-6][1]

  • I feel like there is a lot of truth to this answer, but it doesn't feel like the full answer, especially since the spec also mentions that the implicit grant flow was designed with SPAs in mind. – johnnyodonnell Sep 20 at 20:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.