OAuth1, OAuth2, OAuth... ?

homakov.blogspot.com

11 points·homakov··3 comments

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.

"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).

Some vectors are related to Client, yes, i am just going deeper than spec because we should care about them too

Reply on news.ycombinator.com