The thing this conversation (and Twitter) is missing, is that the OAuth 
protocol neither requires nor relies upon each piece of client software 
having a key of any kind. Twitter wants it to, so it can disable "a 
certain application" (distributed and used by many people) if they 
decide that app is misbehaving. But that's not part of OAuth's security 
model, really, that a client-identifying key gets revealed does not in 
fact compromise the key parts of OAuth's security model.

Trying to know if a given piece of software on the network is "really" a 
copy of "Application X" is not, so far,  a solvable problem. Compare, 
it's the exact same problem that a video hosting website might want to 
solve only letting "their" application (which is distributed to 
end-users) access their videos, and not some other application 
impersonating it.  You can try to make it hard by obfuscating the 
protocol or the keys, but someone can always reverse engineer it 
because, you're distributing your application (and any embedded keys) to 
users. OAuth doesn't try to obfuscate it, that's not OAuth's domain.  [ 
You can also try to make _illegal_ what you couldn't make technically 
impossible, that's what the DMCA does, but that's not OAuth's domain 
either].

On the other hand, instead of trying to confirm that a client on the 
network is "really" a copy of "Application X", if you try to confirm 
that the person _using_ that client knows certain secrets that only a 
user of your server knows -- _that's_ feasible, and that's what OAuth 
does.  Ideally via redirecting the user to the server to enter 
credentials and be redirected back (the same model Shib uses, I say 
'ideally' cause it's the best anyone's come up with thus far, even 
though it has problems with phishing suceptibility). But OAuth (at least 
2.0) has other workflows supported too, for when you can't do that (say, 
you're a Wii application and not a web browser).

Jonathan

Nate Vack wrote:
> On Mon, Sep 20, 2010 at 4:21 PM, MJ Ray <[log in to unmask]> wrote:
>
>   
>> I think FOSS servers would be affected by the published-key spoofing
>> flaw too, wouldn't they?
>>     
>
> They would, but it should be easy(-ish) for each server admin to get
> their own key, which it can then (hopefully!) keep secret. The real
> problem is getting end-users to generate, enter, and register a
> consumer key.
>
> Really really, though, just treat the consumer key as a user-agent
> string. Don't take it seriously. You are free to not make the same
> mistakes as Twitter; your needs are different.
>
> Cheers,
> -Nate
>
>