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