14

Implicit flow is considered to be insecure. I'm aware of two problems:

  1. Confused deputy. But to overcome it you just need to check whether access_token was given to your application. Not a big deal.
  2. XSS attack. So if our access_token was stolen via XSS attack, it can be used to make requests (that are part of the scope we originally requested). It sucks but it's hard to steal access_token as most likely we had it only on our login page and didn't store in app state as it's short-living (I guess that's why Implicit workflow does not support refresh tokens).

It doesn't look too bad. Are there any other security vulnerabilities that I'm not aware of?

Community
  • 1
  • 1
SiberianGuy
  • 24,674
  • 56
  • 152
  • 266

1 Answers1

12

The correct statement should be

implicit flow is insecure relatively to the code flow.

If an attacker wants to steal user access tokens from an app using code flow, then the attacker has to break into the server network and either uncover the app secret or eavesdrop the network traffic from server to Google (which is HTTPS) to get an hold to the access token.

In the implict flow the access token resides in the browser. In this case there are many other possibilities for an attacker to steal tokens without having to compromise a network.

  • XSS (as you already explained)
  • Confused deputy problem (as you already explained)
  • Session fixation issues (using user A's token in user B's session. https://www.facebook.com/FacebookforDevelopers/videos/10152795636318553/ )
  • redirect_url parameter manipulation
  • (possible) token leakage with referrer header
  • Various phishing and social engineering possibilities to trick the users to leak their access token (easier than asking for their password)

But as you said, it is straightforward to mitigate all those errors if you are a security aware developer. But still there is a chance for these vulnerabilities if you implement the implicit flow. Therefore it might be a good idea if you don't deliver the token to browser and handle the token in a server side component (code flow).

SureshAtt
  • 1,891
  • 2
  • 17
  • 22
  • You write that implicit flow is insecure relative to the code flow. I understand that by code flow you mean using code flow with a confidential client (backend). How about 3rd option: using the code flow with a public client (e.g. SPA) i.e. without a secret. This means that the refresh token is delivered to the browser. Is this even worse than implicit flow or is it the same? – Marcel Mar 21 '18 at 15:59
  • You are right, I meant usage of a confidential client in the code flow scenario. For your question I can only answer in format of 'in-theory', because I think it completly depends on the security hardening of the implementation. So "in-theory" I see delivering refresh tokens to the browser is more dangerous than delivering access tokens. Reason: refresh tokens have more lifetime than the access tokens. Validity of access tokens can last for an hour or so, but refresh tokens can be valid for months. So the danger is high. – SureshAtt Mar 23 '18 at 06:54
  • 2
    "In the implicit flow the access token resides in the browser." - Does the token not reside in the browser in a hybrid flow as well? Isn't the point of any of these client side flows to store the token on the client so it can make calls to secured services without passing through a server? – phillyslick Nov 16 '18 at 02:51
  • Thats right. Both cases uses browser side token handling, except that in hybrid flow you get a code which you can use to request tokens in a second step which is secure than implicit token retrieval. I will update the answer accordingly. – SureshAtt Dec 06 '18 at 21:04
  • In the case of public clients who don't have a secure manner for storing client secrets, Authorisation code flow can still be secured using PKCE. See https://www.rfc-editor.org/rfc/pdfrfc/rfc7636.txt.pdf or https://www.oauth.com/oauth2-servers/pkce/. – VietNg Nov 24 '20 at 10:15
  • Does the implicit flow send the token as part of the callback url? – variable Feb 05 '22 at 16:29