Is implicit grant_type in OAuthV2 policy actually useful?

[mirene]

After reviewing the OAuthV2 policy documentation and the OAuthV2 implicit grant_type sample proxy, I am having trouble understanding what is the use of such policy with that grant_type implicit.

The grant_type implicit as per the RFC establishes that no client_secret is required to generate an access token.

The whole point of the access_token is to be able to track it back to an actual app end user and be able to fetch the app end user identifier from it.

If I have have a look at the implicit flow implemented in the sample proxy https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-login-app, I see that step 3 says

On successful authentication, login application invokes this url and it returns the AccessToken to the Apphttps://$org-$env.$api_domain/oauth/token?client_id=$consumerkey&response_type=code&app_enduser={use...

That /token endpoint is not protected in any way. I see that in the README they suggest passing as a parameter the app_enduser in the token request. I am assuming it is to perform that linking between the access_token and the actual user (although in the example they are not using any <Attribute> to store the app_endUser).

In my opinion this is insecure, anybody knowing the app end user identifier and the client_id could call the token endpoint and get a bearer token, without the user having authenticated at all in the login page, because the token endpoint is not protected at all.

Imagine the scenario where we would be saving that app_enduser as an attribute linked to the bearer token and then we have some other endpoint where we verify the access token and fetch that app_enduser from the token and pass it over to a target endpoint. Any malicious user could be actually impersonating the actual app end user.

My question is then, which would be a secure way of linking the actual app end user to the access token for an implicit grant_type using the Apigee OAuthv2 policy. In my opinion, as things are we can only link the app end user to the bearer token using a grant_type that requires client_secret.

[davissean]

This answer isn't going to solve your problem, but may provide some useful links. I look forward to seeing what others may post here.

The RFC has a list of possible threats and mitigations here.

I believe the issue you are referring to is this. "A malicious client could attempt to obtain a token by fraud." The suggested countermeasures are...

- "The authorization server should authenticate the client..." - the OAuthV2 policy will do this.

- "The authorization server should validate the client's redirect URI against the pre-registered redirect URI..." - you can also do this. That way, only the registered app should receive the token

- "After authenticating the end user, the authorization server should ask him/her for consent..." - use scopes to limit the damage if a token is stolen

You can also add a 'state' parameter. There is a nice article here by John Bradley, one of the authors of the OpenId spec, where he rants about the implicit grant and talks about the purpose of the state parameter in avoid CSRF attacks.

[williamssean]

I think the key is to make sure that only the login app can call this token endpoint. You could include an Access Control Policy to help enforce this and you could also include the token endpoint in an Apigee product to further restrict client calls.

[akoo]

+1. This is the best answer I have also come up with. Supposedly only the login app needs to know the Apigee endpoint, and furthermore, it would be ideal that only the login app can call that endpoint.

There are still other security concerns that I think need to be addressed. Let's discuss offline.

[anshul_]

Hi Miren,

When it comes to authorization in the clients, that are implemented entirely using javascript and running in resource owner's browser, it is definitely useful as we don't have any server side code to receive the authorization code and retrieve the corresponding access token, and as obviously, we can't configure our consumer secret in the client's browser javascript.

There should not be any major security concern in the case of implicit oauth, if the connection is over TLS and all the threats mentioned by the RFC are handled carefully, as the access token is being shared only with the resource owner's client browser, which has actually requested for the access token and who is authorized for the same.

So, definitely I find it very useful. Rest, it all depends upon your use case that which type of oauth you have to use.

[Former Community Member]

Traditionally implicit grant is used for untrusted browser apps where there is no specific need to identify/authenticate end user. Admittedly the implicit grant is open to vulnerabilities & technically anyone in the possession of the app key can get an access token & use a protected API. If the end user is part of the mix (3-legged flow) then either the authorization code or password / resource owner grant types are recommended. In either case the user has to authenticate before an access token can be issued to access a protected API.