On Jun 12, 2010, at 3:05 PM, Bernd Stramm wrote:
>> 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. 
> 
> The question is also - why do you care which copy of your app it is?
> People using your app will post silly things, engage in slander of
> other people, commit crimes, plot revolutions. 

Yes, the reason I'm worried is when a token/secret is blocked/revoked, it 
doesn't take down all clients using that same key in my app. Currently I get 
one consumer token/secret so if twitter needs to block one bad user running 
around using the key they reverse engineered from my compiled/obfuscated app, 
it may take down all my users if they block the entire token/secret (hopefully 
twitter investigates and warns me and blocks the offending IPs rather then the 
entire token/secret to give me some time to rev a new key and figure out a 
deployment but that is asking a lot from them). 

Having the ability to issue multiple consumer token/secrets per app, or having 
delegated chaining (like in SSL), I have some ability to mitigate the issue a 
bunch and give twitter the ability to block a much smaller subset of my users 
if a key was extracted and used abusively.  

OAuth 1.0a isn't well designed for desktop/mobile apps and it's more than just 
usability issues that the Twitter gang are trying tackle with things like 
xAuth. It wasn't designed with the thought that keys could be compromised by 
third parties embedded inside apps. I can only hope it's fixed OAuth 2.0.

Just ideas. :-) 

Zac Bowling 
@zbowling  



Reply via email to