Hacker News Reader

Comment by chrisrhoden | Hacker News Reader

Everyone chiming in here is just blatantly, blatantly wrong. OAuth is a solid solution to a very real set of problems.

The fact that you are unaware of the potential problems does not make those problems any less valid.

As someone who has implemented an OAuth flow on Android and iOS, I can agree that it's not easy. But it does solve a serious set of security issues which are raised by having a third party act on behalf of a user. Not only does it permit more fine grained grants to applications that the user trusts to varying levels, it allows a compromised application to have all of its keys invalidated at once. It allows a user to disable a single misbehaving application's access to their account. These are prices worth paying.

Learn what you're whining about. Then deal with it.

View on HN

Not quite sure which (or who's) whining you're having a go at, but as an identity system OAuth is indeed a pile of poo.

First, OAuth1's poorly-spec'd signatures make implementation difficult. That's an accepted and pretty well-documented fact.

OAuth2 removes all crypto and instead relies on bearer tokens and SSL/TLS, while not mandating it. It does away with signatures in favour of ease of implementation. [edit] This is a bad thing.

OAuth2 is also susceptible to man-in-the-middle attacks where a malicious party could gain access if it intercepts a token.

That's a pretty poor implementation.

As an identity provider OAuth 1 and 2 have problems beyond the technical interpretation of the specs, or implementation difficulties. Both fail as an identity system (ref. http://www.identityblog.com/stories/2004/12/09/thelaws.html).

I'd love to hear why you think OAuth is a solid solution.

My primary gripe is with people claiming that oauth doesnt solve a problem. That simply providing a single header is all that is requited. That OAuth is too hard.

OAuth is a set of flows for obtaining tokens. These toekns are, by definition, bound to an application-user grant.

The rest is implementation details.

Which flow are you referring to as being succeptible to mitm attack?

I would also love to hear why you think that identity has anything to do with OAuth or this discussion.

OAuth is an authentication mechanism, meaning it implements a principle of logic stating that a subject is who he/she claims to be (authN), and then asserts that to a relying party (authR). In other words, OAuth establishes identity.

Your question about MITM is answered at http://www.subbu.org/blog/2010/09/oauth-2-0-and-cookie-conve....

OAuth is a mechanism by which an application can be granted authorization by a user to another application.

The identity question is not in any way addressed by OAuth. It is up to the application implementation to handle identifying the user creating the grant.

The link you provided basically establishes the same problem which is always the case - if someone is watching your (unencrypted) traffic, you're hosed.

That authorisation is an assertion of identity. This makes OAuth an identity system inasmuch as WS-Federation and the SAML protocol are identity systems. Technically they're parts of an identity system, making them identity meta-systems.

Maybe, but that has nothing to do with OAuth. One could be completely within the OAuth spec and allow one user to provide grants to act as dozens of other users. You are basically saying that OAuth is not good at something it was never designed to have any say about.

It's as though you're saying that your rolling pin doesn't work well as a meat tenderizer. Yeah, I guess they're related, but that's not what a rolling pin does.

Of course you're right. I'm an idiot. Thanks for setting me straight.

OAuth is not an authentication mechanism. It's an authorization mechanism. This is the source of your confusion.

OAuth2 isn't just about bearer tokens and while the OAuth2 spec doesn't mandate using TLS the bearer token sub-spec does.

Reply on news.ycombinator.com