What is the purpose of the implicit grant authorization type in OAuth 2?

Question

I don\'t know if I just have some kind of blind spot or what, but I\'ve read the OAuth 2 spec many times over and perused the mailing list archives, and I have yet to find a

Answer 1

I've just faced with some article about OAuth 2.0. Author states that the reason behind the Implicit flow is that JS apps were very restricted in there requests:

if you wonder why the implicit type was included in OAuth 2.0, the explanation is simple: Same Origin Policy. Back then, frontend applications were not allowed to send requests to different hosts to get the access token using code. Today we have CORS (Cross-Origin Resource Sharing).

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611

Answer 2

https://tools.ietf.org/html/rfc6749#page-8

Implicit

The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly (as the result of the resource owner authorization). The grant type is implicit, as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token).

When issuing an access token during the implicit grant flow, the
authorization server does not authenticate the client. In some
cases, the client identity can be verified via the redirection URI
used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent.

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.

Answer 3

I think Will Cain answered this when he said " There is no benefit to client credentials for the same reason. (Any client can attempt to use this flow.)" Also consider that the redirect_uri for implicit flow maybe "localhost"--no callback is made from the Authorization Server for the implicit flow. As there is no way to pre-trust the client, the user would have to approve the release of user claims.

Answer 4

It boils down to: If a user is running a browser-based, or "public", (JavaScript) web app with no server side component, then the user implicitly trusts the app (and the browser where it runs, potentially with other browser-based apps...).

There is no 3rd-party remote server, only the resource server. There is no benefit to an authorization code, because there is no other agent besides the browser acting on behalf of the user. There is no benefit to client credentials for the same reason. (Any client can attempt to use this flow.)

The security implications, however, are significant. From http://tools.ietf.org/html/rfc6749#section-10.3:

When using the implicit grant type, the access token is transmitted in the URI fragment, which can expose it to unauthorized parties.

From http://tools.ietf.org/html/rfc6749#section-10.16:

A resource owner may willingly delegate access to a resource by granting an access token to an attacker's malicious client. This may be due to phishing or some other pretext...

Answer 5

I'm not sure that I understand correctly the answer and Dan's comment. It seems to me that the answer has stated some facts correct but it does point out exactly what OP asked. If I understand correctly, the major advantage of the implicit grant flow is that a client like JS app (e.g Chrome extension) doesn't have to expose the client secret.

Dan Taflin said:

...in the authorization code flow the resource owner never needs to see the access token, whereas in javascript clients that's unavoidable. Client secret could still be kept from javascript clients using authorization code flow, however..

Perhaps I misunderstood you, but the client (JS app in this case) must pass the client credential (client key and secret) to the resource server in the authorization code flow, right ? The client secret cannot be "kept from JS".

Answer 6

In the implicit flow if the user's browser is corrupted (evil extension / virus ) then the corruption gets access to the user's resources and can do the bad stuff.

In the auth flow the corruption can't because it doesn't know the client secret.