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?

Posted by Blake Dournaee on 1:37 PM 1 comments

Intel(R) SOA Expressway Demo at JavaOne

JavaOne is this week at Moscone center in San Francisco and I've been putting together a live demo of Intel(R) SOA Expressway. The plan is to show some perimeter defense, delegated authentication and message throttling functions. The scenario has three threads running, good requests, bad requests (auth faults) and bad requests (XML attacks). This set up is perfect for getting all of the pretty colors to show on the Intel(R) SOA Expressway dashboard!

I've got SOA Expressway running on an old IBM t43p (single core) laptop on 32-bit Red Hat AS4. This is really for convenience since the laptop is small and easy to lug around. What's interesting is that even on this ancient machine Intel(R) SOA Expressway is extremely reliable - I had it going all weekend and it converged to about 8000 messages per hour, which actually limited by the client I'm using, which is SOAP UI.

If anyone is around this week, please come by come check out the demo.

Blake

Posted by Blake Dournaee on 5:15 PM 3 comments

Followers

About Me

My photo
I have been working in the XML/SOA and security space for about 10 years. I currently work at Intel Corporation in their software group. I wrote the first book on XML Security and am a co-author of SOA Demystified from Intel Press. My interests are an eclectic mix of computing, security, business, technology and philosophy