Hacker News Reader

Comment by peter_l_downs | Hacker News Reader

I've written an OAuth2 server implementation and to be honest, I still don't really understand why people use OAuth2 instead of OAuth1.0a. The minimum amount of work you have to do to write an implementation that complies with the spec leaves you open to all sorts of security issues (as Homakov continues to detail), no two providers implement the same parts of the spec so writing clients isn't really all that easy, and the "security" features don't really seem all that secure. For example, refresh tokens, what the fuck? If an attacker can steal your access token why would you assume that your refresh tokens are safe? How is it ok to say "well, even if your access token is stolen at least it will expire eventually, so don't worry"?

/rant.

View on HN

It requires the client id and secret to obtain a refresh token, some also choose to skip this and ask the user to re-authenticate completely.

I agree that people implement it differently so vastly different that it takes almost 40 sources to compile a decent down-to-earth explanation of common practices (same for OAuth 1.0a). However, that doesn't make the protocol bad, it makes the implementation bad, you can avoid XSS, OOS Origin Attacks, and the others with the exception of Vector attacks, but both are vulnerable to this.

That's fair, I guess what I'm trying to say is that if the spec leads to broken/vulnerable implementations in the majority of cases there might be reason for concern. One thing I think OAuth 2 gets right is the entire concept of scoped authorization; although not unique to OAuth2, it's now familiar to users largely because Facebook and Google adopted it through OAuth 2.

As someone who was present at Google working at OAuth at the time OAuth 2.0 was negotiated: the way to interpret refresh tokens is in the context of a large organization like Google or Facebook, not a small website. A refresh token, which is powerful, would only be presented to a single endpoint which could had different logging and security considerations.

But yes, a lot of damage can be done in an access token timeout.

The point of refresh tokens is not to be more secure than access tokens, but to make some implementations more convenient.

- It's easier to change the format of short-lived access tokens, since you know there are no valid tokens hanging around after the expiry time. In contrast you may want refresh tokens to be valid for months or years.

- Every endpoint in your system must read access tokens, but only your authorization endpoint needs to read refresh tokens.

- In some cases it is acceptable to do checks only when verifying refresh tokens, e.g. checking for revocation only when refreshing the tokens, while access tokens are trusted implicitly while valid.

For a simple implementation you can just issue long-lived access tokens, use of refresh tokens is optional.

I had to write one too, and feel exactly the same way.

The common argument for OAuth2 seems to be, "Well, Google and Facebook are doing it, so it must be worth something." Of course Google and Facebook are doing it; it lets them play the role of the official identity keepers of the internet.

Those companies are known to pick the best and the brightest engineers, yet exploits were found in even their versions of OAuth2. If they couldn't produce a secure implementation, then can anyone?

Reply on news.ycombinator.com