

OAuth1, OAuth2, OAuth... ? - homakov
http://homakov.blogspot.com/2013/03/oauth1-oauth2-oauth.html

======
eric970
Most of the attack vectors the author brings up don't relate to the OAuth2
spec per say, but to a poor implementation of it. Not escaping HTML, having
your users getting phished, allowing arbitrary redirect_uri's to be set...
These are things a security-conscious OAuth2 provider would never allow to
happen. These are all things we have consciously avoided in our
implementation.

I feel the author's frustration with the spec. I think that the OAuth2 spec
could do a better job of outlining best practices and security, but calling it
a terrible spec over the potential of poor implementation isn't right IMO.

Also, stealing an access token is far from "Game Over', as the author states.
They're short lived and meant to mitigate the damage done by having one or
even several leaked. Getting your hands on a Refresh Token would be closer to
"Game Over". Although even then, it'd be trivial to have the compromise
reported and expire the Refresh Token of that client and subsequently all
access tokens.

~~~
rauar
"They're short lived and meant to mitigate the damage done by having one or
even several leaked."

No. Reducing the time frame does not limit what can be done with illegal
access at all.

And there's nothing in the spec. afaik which says at all what short lived
means exactly (in terms of seconds, minutes whatever). Probably short-lived
needs to be long-living enough to perform some operation in the context of the
applications author(s) - otherwise the token would be pointless. In the same
time an attacker could use it without any issue as well (minus time of the
take-over action).

