On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
> Application authors are being asked to devote substantial resources to
> the OAuth conversion, but OAuth provides no security for application
> authors!

It does from a web app perspective which is the primary design goal of OAuth 
since there would be no distribution of your secret in that scenario.

With OAuth, the issue is that if you are distributing secrets out that are 
embedded in your app, even with all the measures you can take to encrypt and 
obfuscate them, they can still be extracted at some point if someone has time. 
The issue is compounded since the app uses the same key universally in all the 
versions they ship that work so you are screwed if someone does yank your key. 
All versions you shipped are at risk then. Your only recourse is to rev your 
secret and force all your users to upgrade their apps to get new keys.  In 
practice, this isn't that bad since twitter isn't hosting credit card data or 
anything of major risk and you basically devolve into the same issue we had 
with app identify we had with basic auth and passing clear text source ids 
(except that maybe now all your apps are crippled).

I've been pondering how you could solve this from my experience with solving 
these issues with SSL/TLS. One idea is having a sort of delegation chain where 
I could generate a new delegated secret for each copy of my app I distribute 
rather then using my same static secret directly in all my apps and then the 
client could pass the authentication chain up when it goes to Twitter to get an 
access token. 

This is similar to the idea of having the ability to issue multiple secrets 
against a single app like I was suggesting earlier which could work with the 
OAuth spec today. However a delegation system would be even better so I could 
issue delegated secrets at will without going back to Twitter, although that 
idea would probably require extending the OAuth spec to handle passing signed 
delegation chains of some kind. 

I'm hoping OAuth 2\WRAP allows this somehow since it builds on SSL/TLS instead 
of reinventing the wheel. There is a lot OAuth could learn from SSL/TLS which 
I'm hoping that OAuth 2/WRAP takes full advantage of in solving. :-)

Right now though, one solution if you are ultra paranoid if you are going to 
distribute software, is to proxy the calls from your own software through your 
own web service (which would render the ease of use you get from xAuth moot but 
you are sacrificing usability for security). 

Zac Bowling

Reply via email to