Live data from Hacker News

OAuth 2.0 and the Road to Hell

hueniverse.com

11–20 of 73 posts

Re: OAuth 2.0 and the Road to Hell

#11
Yes, this is sad. And it happens all the time.

Exactly the same thing happened to the whole Semantic Web effort at W3C. It basically got overtaken by enterprise and now it is of little interest or use to regular web developers.

Re: OAuth 2.0 and the Road to Hell

#12

It saddens me to see OAuth 2.0 in this state. As someone who’s made really minor contributions to 2.0 (and thus listed as a contributor in the spec), I have been really looking forward to it being finished and ready for production use (where production use means no more drafts). I stopped following the mailing list last year because most of the threads seemed all too familiar or out of my realm of knowledge to contri…

Please do so! I'll help with what I can and little I know.

Re: OAuth 2.0 and the Road to Hell

#13
Hang on a minute, from where I'm standing as a client developer OAuth 2 is much better than OAuth 1.

Firstly, reducing the burden of tricky and unnecessary crypto code on the client is useful.

Secondly, some of the article's points don't even make sense, like saying tokens are necessarily unbounded, which isn't true. The issuer can easily include the client_id in the token and check for its revocation when used, as it did in OAuth 1. The same is true for self-encoding: clients don't have to issue self-encoded tokens and can instead issue unique id-style tokens with long expiry times. As for refresh, that's unfortunate but issuers could easily work around it if the OAuth 1 way was preferable.

In short, OAuth 2 is simpler to implement for the client in exchange for being slightly harder on the issuer, whilst also being more flexible. Yes, it relies on SSL for security. So does your bank.

Re: OAuth 2.0 and the Road to Hell

#14

It saddens me to see OAuth 2.0 in this state. As someone who’s made really minor contributions to 2.0 (and thus listed as a contributor in the spec), I have been really looking forward to it being finished and ready for production use (where production use means no more drafts). I stopped following the mailing list last year because most of the threads seemed all too familiar or out of my realm of knowledge to contri…

Yes, that would be great, as I'm not sure there are any good docs on writing a OAuth provider.

Re: OAuth 2.0 and the Road to Hell

#16

Hang on a minute, from where I'm standing as a client developer OAuth 2 is much better than OAuth 1. Firstly, reducing the burden of tricky and unnecessary crypto code on the client is useful. Secondly, some of the article's points don't even make sense, like saying tokens are necessarily unbounded, which isn't true. The issuer can easily include the client_id in the token and check for its revocation when used, as i…

Tricky and unnecessary crypto code: you mean HMAC, or something else? I've written code for Amazon EC2 that used HMAC and it wasn't too bad, and I'm now trying to evaluate whether to use OAuth 2, OAuth 1 or something else. Is there other cryptographic coding in OAuth 1 apart from the HMAC signature?

Re: OAuth 2.0 and the Road to Hell

#17
post #16

Hang on a minute, from where I'm standing as a client developer OAuth 2 is much better than OAuth 1. Firstly, reducing the burden of tricky and unnecessary crypto code on the client is useful. Secondly, some of the article's points don't even make sense, like saying tokens are necessarily unbounded, which isn't true. The issuer can easily include the client_id in the token and check for its revocation when used, as i…

Tricky and unnecessary crypto code: you mean HMAC, or something else? I've written code for Amazon EC2 that used HMAC and it wasn't too bad, and I'm now trying to evaluate whether to use OAuth 2, OAuth 1 or something else. Is there other cryptographic coding in OAuth 1 apart from the HMAC signature?

No, the HMAC-SHA1 signature is the only crypto needed in OAuth 1.
Post reply on HN