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

21–30 of 50 posts

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

#21

Post by scrollaway »

[deleted] wrote: post #20

[deleted]

Ah, but if only people switched to Persona.

If only people looked into it more than 5 minutes and realized that Persona is still maintained and is by far the best way to do authentication on the web. Really, the most correct protocol out there.

But then of course, if only Mozilla had a marketing team worth a damn and didn't make it look like they gave up on the whole thing in the first place, we wouldn't have this situation.

I get sad trying to promote it. I get the feeling that whoever is in charge of decisions around Persona has no idea how important a project like it is for the web. Everybody is tying a core and extremely security-sensitive part of their websites, authentication, to other websites in a non-decentralized way. And every time there's a damn post about "Facebook auth is down!", "Twitter auth is down!"... how long is it going to be until those are down for good and people just can't log in anymore?

Blergh. Sad.

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

#22

Post by nijiko »

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.…

Thank you for this, was about to post the exact same reply.

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

#23

Post by nijiko »

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 XSS, OOS Origin Attacks, and the others with the exception of Vector attacks, but both are vulnerable to this.

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

#24

Post by Luker88 »

I have written an implementation for OAuth1 and OAuth2.

I liked the protocol/framework so little that I started implementing a new one. But soon I realized that a lot of the difficulties come from having this thing run on top of HTTP, and that I could not access any security feature of the lower levels.

So (IMHO) everything implemented on top of HTTP, or the whole idea of having isolated layers of security is doomed to have problems and will cause headaches to anyone working with it, aside from requiring developers to be security experts.

But I still didn't stop and my master thesis now is a complete secure rewrite of protocols from tcp, tls to OAuth.

The project is on fenrirproject.org if you want to comment it. Lots of work, I am aiming to an implementation in half a year. Please feel free to drop me a line.

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

#25

Post by tboyd47 »

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…

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?

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

#26

Post by scott_w »

scrollaway wrote: post #21
[deleted] wrote: post #20

[deleted]

Ah, but if only people switched to Persona. If only people looked into it more than 5 minutes and realized that Persona is still maintained and is by far the best way to do authentication on the web. Really, the most correct protocol out there. But then of course, if only Mozilla had a marketing team worth a damn and didn't make it look like they gave up on the whole thing in the first place, we wouldn't have this si…

I agree with you. I looked into Persona to implement an SSO for our products (provider and client). I've never been able to understand OAuth in the context of an authentication mechanism so I left it.

However, Persona has very poor library support, especially for providers. The support channels are also very small, so you're not likely to find other people fixing the same issues.

I ended up just hacking an OpenID provider libary to get the result I wanted. It's a real shame because Persona seemed to be designed for circumstances very similar to what I wanted to do.

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

#28

Post by nickik »

scrollaway wrote: post #21
[deleted] wrote: post #20

[deleted]

Ah, but if only people switched to Persona. If only people looked into it more than 5 minutes and realized that Persona is still maintained and is by far the best way to do authentication on the web. Really, the most correct protocol out there. But then of course, if only Mozilla had a marketing team worth a damn and didn't make it look like they gave up on the whole thing in the first place, we wouldn't have this si…

Well, you have convinced 1 person to look into it. Whats the best article, blogpost to read.

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

#29

Post by scrollaway »

nickik wrote: post #28
scrollaway wrote: post #21

Earlier quoted context omitted.

Ah, but if only people switched to Persona. If only people looked into it more than 5 minutes and realized that Persona is still maintained and is by far the best way to do authentication on the web. Really, the most correct protocol out there. But then of course, if only Mozilla had a marketing team worth a damn and didn't make it look like they gave up on the whole thing in the first place, we wouldn't have this si…

Well, you have convinced 1 person to look into it. Whats the best article, blogpost to read.

Unfortunately, like scott said above, persona has very poor overall support. The best resources are the official ones:

https://developer.mozilla.org/en-US/Persona

I strongly believe in the protocol, but I have stopped believing in Mozilla to actually do something with it. They have absolute technical gold (yes, it has a couple of issues, they are minor overall) and they just aren't doing anything with it.

I still encourage people to actually implement it because, unlike with centralized protocols, we don't actually need Mozilla for it to work (persona servers are open source and the whole protocol is decentralized). But I have very little faith in ever getting the critical mass necessary for a majority of devs to adopt it without Mozilla promoting it more. (And they were so close, too, with their gmail gateway...)

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

#30

Post by binky56 »

rcxdude wrote: post #13
untog wrote: post #5

Earlier quoted context omitted.

I only partly agree with you. Every developer does not need to know exactly how HTTPS encryption algorithms work, just whether they are secure or not.

"Secure or not" is not a meaningful distinction. "Secure" means a lot of different properties which may be of varying importance to different people and applies to the whole system, not individual components. So the only meaningful interpretation of 'secure' for a subcomponent is "Does it achieve the security properties it aims to?". It does not excuse from learning what those properties are, what they mean, and thei…

Valid point. Even encryption is only "secure" for a limited time. I could sniff the traffic, store the data and wait until the encryption is crackable. For most transactions that is good enough as our passwords are probably not relevant in 10 years. For some transactions it may not be enough because you probably would have the same bank account in 10 years. Granted the cost to capture and save for a later date probably outweighs the potential to exploit.

At the same time I would not expect a front end JS/CSS developer to know the specifics of the entire system, only the parts of his/her subsystem. That is to say they should know XSS/CSRF like the back of their hand, but probably don't need to fully understand a stack overflow. On the other hand if you write C/C++ or any other low/mid level language XSS probably means nothing to you and stack overflow is highly important.

Post reply on HN