CODEWITHSUNDEEP
securityoauth-2.0oauth2client
wonster
wonster

Reputation: 746

OAuth 2.0 Implicit Grant Flow - clientId and accessToken exposure security

Since OAuth 2.0 Implicit Grant Flow exposes its mechanism e.g. using JavaScript, in the client app to the resource owner, the client Id and the access token are exposed. I have not been able to find a clear answer on what can be done to prevent from exploiting the exposure.

What are some measures to prevent problems with the following scenario? If it's apparent that I am not understanding the flow correctly, please do point out.

Scenario

Client A - a legit client who has been granted its own unique client Id from the authorization server.

Client B - a client the authorization server is not aware of, copies the client Id of Client A, draws in innocent resource owners and uses their access tokens to gain access to their private information.

These are some options I can think of to fix the issue.

  1. Create an IP white list and map to each known client. Check against the authorization server when authorizing and calling the resource server.
  2. Set throttling on the end points of the resource server to detect abnormal activities.

Upvotes: 2

Views: 840

Answers (2)

kevin
kevin

Reputation: 491

The token is secured using SSL between the client and the server. Therefore the content is encrypted but the URI is not. You can put store the token in the html body because it is secure with the exception of browser add ons. Don't use third party content servers to host JavaScripts, if they are compromised their scripts can read your html. The user can see the token and copy it to their own app if they want but its protecting their resources so... Ultimately I like Implicit flow because of its simplicity.

Ultimately the servers handling of the token can be a problem out of your control. Chose a server that does not include the token in the URI, its not safe. Similarly your shouldn't post back to the server sensitive information in the URL.

If you find a library that guarantees security, please post it.

Upvotes: 0

user3101375
user3101375

Reputation: 121

Well, this is the reason why the OAuth specification (RFC 6749) warns against about security weaknesses of the implicit flow in Section 10.6. It's not clear that the counter-measures you describe would be effective in a general setting on the internet. For example, IP headers are insecure and can be easily spoofed. I would only use the implicit flow for the applications that require the lowest level of security (e.g., read-only display of information).

Upvotes: 2

Related Questions