Where art thou, OAuth? Really now...
I've been digging into OAuth lately, which is a protocol for delegated authentication and authorization. It seems to be useful for cases where the end user is authorizing an intermediary (called a consumer) to access a specific resource for one-time access. This means that the end user is the policy decision point, rather than a centralized PDP.
The protocol certainly looks interesting, but I've got a problem with it. My problem is that for browser interactions, the user is not given the equivalent of an SSL "lock" or other indicator that this is truly an OAuth protected interaction. This means that OAuth alone is not enough to reduce phishing attempts as described here. A rogue website can just tell the user to sign in and then claim its only accessing data one time - there is no way for the user to verify this fact. Further, we know from the days of X.509 certificates that users can't possibly understand a basic trust relation, so having them understand a three-legged protocol with a shared secret is a stretch. Worse, the presentation argues that OAuth helps reduce the password anti-pattern, but a username and password is obviously required by the user - most users won't know the difference. Once more people move to OAuth, phishing sites will just make it appear as if they are doing OAuth - it will be a zero-sum game. We need the equivalent of an "OAuth lock" in the browser for this protocol to be used for high-value transactions.
Given that users must trust the website they are interacting with in the end, the simpler approach is to have websites publish a privacy and security policy that clearly says that access to service provider websites will be done with user credentials, but that the credentials will only be used once and not saved. Doesn't this achieve the same result with less code to write and less complexity? Is it more prudent for me to trust the website I am at or trust that the website has successfully implemented a complex, multi-hop security protocol?
