[Robin_Message]

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.

[davedx]

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?

[Robin_Message]

I could have been clearer. It's not the crypto primitives that are tricky - as people say, HMAC is a library. It's the need to assemble a irritating number of parameters and build a signature of the correct ones for each call, and provide nonces, and I don't know what else but it depends on me not to screw it up and its too big for me to be confident of that, and I'm not sure I trust library authors. Granted, it's not rocket surgery and there are libraries, but OAuth 2 for a client is literally 25 lines of code – look at https://developers.facebook.com/docs/authentication/server-s... – so I don't care if someone can implement HMAC in 12 lines of code.

My point was that OAuth 2 improved in a number of ways for clients and is at least as flexible for the issuer as OAuth 1, so I think the author is just disturbed by the trust of SSL for security, and the crappy, slow standardisation process, and ended up going overboard.

[nigelsampson]

The biggest problem I had with OAuth 1 was that if you messed up anything chances are all you got back from the server was "Signature Invalid".

You're then stuck trying to find out where you had gone wrong with no guidance. The last time was due to an incorrect content type on the post. A coworker accidentally had the key and secret the wrong way around.

Both scenarios has the same error and you're often stuck groping around for a solution.

[justincormack]

That is hard to fix with crypto stuff. Good public test cases as part of the spec help, and worked examples.

[tvdw]

No, the HMAC-SHA1 signature is the only crypto needed in OAuth 1.

[Xylakant]

Like literally every programming language should have an implementation of HMAC-SHA1 around and lacking that, at least a SHA1 implementation. It's pretty trivial to build HMAC-<HASHFUNCTION> if you have <HASHFUNCTION> around. A working python implementation is literally 12 lines long.

Now if you don't have a SHA1 implementation in your programming language, that's a different problem.

[davedx]

Huh, strange then, I really didn't find it that hard. Then again, the EC2 docs are pretty good.

Just decided with my boss we're going to roll with a hybrid approach. Spent too much time reading through all these standards and not enough time thinking and coding.