

OAuth 2.0 (without Signatures) is Bad for the Web - abraham
http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/

======
pilif
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.

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

------
vlisivka
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).

~~~
lalinsky
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?

