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 user

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.