OAuth 2 Grant Type Implicit Security §

Implicit flow is insecure relatively to the code (and hybrid) flow.

If an attacker wants to steal user access tokens from an app using code (hybrid) 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 implicit 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
• Confused deputy problem
• Session fixation issues (using user A’s token in user B’s session)
• 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 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).

Main differences of OAuth implicit grant type and authorization code grant type §

• This flow does not authenticate the identity of the application, and relies on the redirect URI (that was registered with the service) to serve this purpose.
• The access token is given to the user-agent to forward to the application, so it may be exposed to the user and other applications on the user’s device.

Reference §

https://stackoverflow.com/questions/41972081/what-are-the-security-risks-of-implicit-flow authentication - Why is there an “Authorization Code” flow in OAuth2 when “Implicit” flow works so well? - Stack Overflow