{ Community }
  • Academy
  • Docs
  • Developers
  • Resources
    • Community Articles
    • Apigee on GitHub
    • Code Samples
    • Videos & eBooks
    • Accelerator Methodology
  • Support
  • Ask a Question
  • Spaces
    • Product Announcements
    • General
    • Edge/API Management
    • Developer Portal (Drupal-based)
    • Developer Portal (Integrated)
    • API Design
    • APIM on Istio
    • Extensions
    • Business of APIs
    • Academy/Certification
    • Analytics
    • Events
    • Hybrid
    • Integration (AWS, PCF, Etc.)
    • Microgateway
    • Monetization
    • Private Cloud Deployment
    • Insights
    • IoT Apigee Link
    • BaaS/Usergrid
    • BaaS Transition/Migration
    • Apigee-127
    • New Customers
    • Topics
    • Questions
    • Articles
    • Ideas
    • Leaderboard
    • Badges
  • Log in
  • Sign up

Get answers, ideas, and support from the Apigee Community

  • Home /
  • Edge/API Management /
avatar image
4
Question by mirene · Aug 09, 2016 at 09:09 AM · 631 Views oauthv2

Is implicit grant_type in OAuthV2 policy actually useful?

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≈p_enduser={userId}

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.

Comment
Add comment Show 1
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image pbhogill ♦ · Aug 15, 2016 at 05:23 PM 0
Link

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.

Close

3 Answers

  • Sort: 
avatar image
2

Answer by williamssean · Aug 12, 2016 at 03:53 PM

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.

Comment
Add comment Show 1 · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Alex Koo ♦♦   · Dec 14, 2016 at 04:41 PM 0
Link

+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.

avatar image
1

Answer by davissean   · Aug 09, 2016 at 09:27 AM

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.

Comment
Add comment · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image
1

Answer by aagrawal · Aug 15, 2016 at 12:07 AM

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.

Comment
Add comment · Link
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

Follow this Question

Answers Answers and Comments

42 People are following this question.

avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

Related Questions

is there a verify refresh token policy? 5 Answers

OAuthV2 Fault not being raised 1 Answer

How to Hide a flow variable 1 Answer

My REST endpoints are OAuth2 secured. how do test these endpoints from the swagger UI console 1 Answer

I unable to authenticate user details of Apigee Sandbox using OAuth2 1 Answer

  • Products
    • Edge - APIs
    • Insights - Big Data
    • Plans
  • Developers
    • Overview
    • Documentation
  • Resources
    • Overview
    • Blog
    • Apigee Institute
    • Academy
    • Documentation
  • Company
    • Overview
    • Press
    • Customers
    • Partners
    • Team
    • Events
    • Careers
    • Contact Us
  • Support
    • Support Overview
    • Documentation
    • Status
    • Edge Support Portal
    • Privacy Policy
    • Terms & Conditions
© 2019 Apigee Corp. All rights reserved. - Apigee Community Terms of Use - Powered by AnswerHub
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Create an article
  • Post an idea
  • Spaces
  • Product Announcements
  • General
  • Edge/API Management
  • Developer Portal (Drupal-based)
  • Developer Portal (Integrated)
  • API Design
  • APIM on Istio
  • Extensions
  • Business of APIs
  • Academy/Certification
  • Analytics
  • Events
  • Hybrid
  • Integration (AWS, PCF, Etc.)
  • Microgateway
  • Monetization
  • Private Cloud Deployment
  • Insights
  • IoT Apigee Link
  • BaaS/Usergrid
  • BaaS Transition/Migration
  • Apigee-127
  • New Customers
  • Explore
  • Topics
  • Questions
  • Articles
  • Ideas
  • Members
  • Badges