Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OAuth1, OAuth2, OAuth..? (2013)

homakov.blogspot.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: OAuth1, OAuth2, OAuth..? (2013)

#31

Post by peter_l_downs »

nijiko wrote: post #23
peter_l_downs wrote: post #14

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, a…

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…

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.

Re: OAuth1, OAuth2, OAuth..? (2013)

#32

Post by tveita »

peter_l_downs wrote: post #14

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, a…

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.

Re: OAuth1, OAuth2, OAuth..? (2013)

#33

Post by dmak »

ademarre wrote: post #9

With the exception of vector #6, this is pretty much a list of implementation flaws, not protocol flaws. It's as if he's trying to say that the protocol isn't written defensively enough or foolproof enough for implementors, and he might have a good point if he simply said that, but he never did. Even with an OAuth library for the nuts and bolts, to implement an OAuth2 authorization server requires grokking the spec.…

How does Google police registered clients? Does anyone else do this?

Re: OAuth1, OAuth2, OAuth..? (2013)

#34

Post by ademarre »

dmak wrote: post #33
ademarre wrote: post #9

With the exception of vector #6, this is pretty much a list of implementation flaws, not protocol flaws. It's as if he's trying to say that the protocol isn't written defensively enough or foolproof enough for implementors, and he might have a good point if he simply said that, but he never did. Even with an OAuth library for the nuts and bolts, to implement an OAuth2 authorization server requires grokking the spec.…

How does Google police registered clients? Does anyone else do this?

Good question. I dug up the e-mail from 2012 and here's what the Google Security Team told me:

> We're deploying some abuse detection and reactive measures to deal with impostors that might try to abuse this sort of attack.

Surely any OAuth2 service provider will disable clients that are caught misbehaving.

Re: OAuth1, OAuth2, OAuth..? (2013)

#35

Post by new299 »

smt88 wrote: post #19
smt88 wrote: post #3

Earlier quoted context omitted.

That's the kind of attitude that leads to massive security flaws. Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people.

To the downvoters: if you stick your head in the sand, you'll do things like using MD5 for password hashing and logging into remote servers as root. I see basic mistakes like that all the time. I'll reiterate (and this is a general comment, not necessarily about HTTPS): if you aren't willing to understand how software works and how people attack it, don't write it professionally. It's part of your job and your respon…

I think it's because you wrote:

"Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people."

Which is a very direct and negative comment. Not all software significantly touches on security. People write one off programs for generating musical compositions, one off pieces of data analysis. Proof of concepts that aren't designed to ship and any number of non-internet connected programs where the security considerations are less significant.

If you didn't mean those applications, then your comment amounts to "people writing security sensitive software should be mindful of security". Which is so redundant as to be meaningless.

Telling people "you have no right to be programming" on a hacker forum is unlikely to make you many friends.

Re: OAuth1, OAuth2, OAuth..? (2013)

#36

Post by oautholaf »

peter_l_downs wrote: post #14

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, a…

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.

Re: OAuth1, OAuth2, OAuth..? (2013)

#38

Post by smt88 »

new299 wrote: post #35
smt88 wrote: post #19

Earlier quoted context omitted.

To the downvoters: if you stick your head in the sand, you'll do things like using MD5 for password hashing and logging into remote servers as root. I see basic mistakes like that all the time. I'll reiterate (and this is a general comment, not necessarily about HTTPS): if you aren't willing to understand how software works and how people attack it, don't write it professionally. It's part of your job and your respon…

I think it's because you wrote: "Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people." Which is a very direct and negative comment. Not all software significantly touches on security. People write one off programs for generating musical compositions…

Yes, I was being direct and negative. I was responding to someone who wanted to be a developer and not have to understand security. That kind of attitude/culture is what makes so many thousands of widely-used applications vulnerable. Security shouldn't be an afterthought. People trust us to write secure software, and few of us do.

The key word in my comment was "professionally". I'm not telling someone experimenting for fun to learn detailed security implications. I'm talking to someone who is charging someone (clients or employers) for their work.

And what I said is, sadly, not so redundant as to be meaningless because I was responding to someone who said "I don't want to be mindful of security, just tell me if [XYZ] works." So obviously it DID need to be said!

Post reply on HN