OAuth 2.0 (without Signatures) is Bad for the Web

hueniverse.com

13 points·abraham··4 comments

I love OAuth 1.0 in conjunction with RSA signatures (even though OAuth 1.0 left key exchange unspecified). With RSA, you never need to store a shared secret on either of the three ends and you still get revokable authentication.

I'm always terribly afraid of storing something on the server that needs to be in a form in which it's useful for a malicious party to impersonate other users. Be it a clear text (or reversibly encrypted password), a MD5 hashed password stored for HTTP digest authentication or a HMAC-SHA1 OAuth token.

I know it might seem complicated, but authentication - especially once a third party gets involved is complicated. That's why you read into the issue, learn what you need to know and use pre-build libraries.

This brings up what has been bothering me about OAuth 2 as well. Signing is important! With FireEagle, we used SSL for everything, but we still required signing. That's because often client's don't check SSL certs.

OAuth 1.0 is mix of authentication problem (as solved by HTTP authentication) and connection protection problem (as solved by SSL) and cross-site authentication problem.

OAuth 2.0 is mix of authentication problem (as solved by HTTP authentication) and cross-site authentication problem.

I hope, OAuth 3.0 will solve cross-site authentication problem only, so I can use standard HTTP or cookie-based authentication solutions and standard HTTPS protocol (when necessary).

Authentication is an important part of OAuth for me. If you fall back to standard HTTP authentication (Basic/Digest), client-side applications need to know the user passwords. This isn't perfect even when there are passwords, but it doesn't work at all when there are no passwords (like when the site is an OpenID consumer). Isn't that the problem OAuth was trying to solve?

Reply on news.ycombinator.com