Well, if you want to distribute an application to users that will enable 
them to log in to _their own personal information_, without them ever 
having to enter credentials in a workflow started by that application, 
that's not going to happen, cause it's kind of impossible.

But if you just want to "publish an OAuth-using client that's not easy 
to impersonate" -- well, it depends on what you mean. Do you mean you 
want the server to know that the client application, that is distributed 
to end-users,  is "The Twitterific Client", in a crypto-secure way?  You 
indeed can not do that. This is not OAuth's fault, it's the universe's 
fault.  There is no way to do this absolutely reliably, although the DRM 
people sure try, and Facebook tried, causing the problems that blogger 
was complaining about. There's no other solution that will do that 
either, it's not a unique failing of OAuth, and it's not the problem 
domain OAuth was trying to solve, mainly.

Do you not care about authenticating that the client software is "The 
Twitterific Client", but you just care about knowing that Joe Smith has 
authorized it (whatever it is) to access Joe Smith's twitter account?  
Ah, now THAT is indeed the use case of OAuth. The first one was not the 
use case of OAuth, and Facebook trying to use OAuth anyway to accomplish 
it is what causes the problems.

How do you do this?  By, as mentioned in the blog post you cited, 
following the OAuth specs recommendations, unlike Twitter:

"In many applications, the Consumer application will be under the 
control of potentially untrusted parties. For example, if the Consumer 
is a freely available desktop application, an attacker may be able to 
download a copy for analysis. In such cases, attackers will be able to 
recover the Consumer Secret used to authenticate the Consumer to the 
Service Provider. Accordingly, Service Providers should not use the 
Consumer Secret alone to verify the identity of the Consumer." [right 
from the OAuth spec; that Twitter may have ignored this is not OAuth's 
fault].


Yes, to do this, OAuth requires one of two workflows, neither ideal:
1) Redirect to Twitter where the user logs in, and is then redirected 
back (Ie, similar to Shibboleth or other SSO flows we may be familiar 
with). Problems -- A) this may be hard to do in a non-web applications.  
B)  Succeptible to fishing.  [Note Shibboleth, OpenID,  and most other 
SSO login systems have the exact same issues].

2) Have the user enter their twitter login/password directly in client 
application, which then sends it on to twitter. Problem: Giving your 
twitter credentials to someone else.   It's a _little_ bit better than 
it seems because the OAuth framework allows the client app to 
immediately discard those credentials after using them to get a token 
from Twitter, so the client doesn't have to be responsible for ongoing 
protection of sensitive information.

Not ideal, true. But no other solution is going to do better, because 
that's just how the universe works, unless some genius can come up with 
something nobody's thought of yet. 

Your arguments are against implementing OAuth poorly, and a useful 
reminder that doing anything security related requires thinking 
carefully, and OAuth doesn't get us out of that with an automatic 
solution that will Just Work without thinking.  But your arguments are 
not against OAuth. Maybe they're against trying to do remote 
authentication between two servers AT ALL because of the inherent 
problems with such, heh.

Jonathan




MJ Ray wrote:
> Jonathan Rochkind wrote:
>   
>> Can you give some details (or references) to justify the belief that 
>> OAuth isn't ready yet?  (The fact that Twitter implemented it poorly 
>> does not seem apropos to me, that's just a critique of Twitter, right?).
>>
>> I don't agree or disagree, just trying to take this from fud-ish rumor 
>> to facts to help me and others understand and make decisions.
>>     
>
> The problems with Twitter's poor implementation have been compounded
> by bad management decisions like switching off HTTP authentication and
> an amazing policy on key invalidation, but I agree that's not the
> fault of OAuth.
>
> The key point is in the http://bit.ly/c88aa7 that Joe posted: how can
> one publish an OAuth-using client that's not easy to impersonate?
>
> Requiring every user to fill out registration forms and cut-and-paste
> key strings into a client is not going to fly, so it seems like it
> can't be done except on a very locked-down platform, because the
> consumer secret is distributed to users' systems in the app.  So you
> either ignore the key parts of the 1.0a version (which means that the
> standard needs revision IMO, so is not ready yet), or you jump ahead
> to the 2.0 draft, which is not ready yet because it's still a draft.
>
> Personally, I think the right answer would have been to keep HTTP
> authentication over HTTPS and have some slick way of creating
> subsidiary usernames with limited privileges for apps, but there's
> probably some better solution that I'm missing.
>
> Aside 1: will 2.0 ever work and be ready?  Its editor Eran
> Hammer-Lahav criticises its current state at
> http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/
>
> Aside 2: to be fair, I'll point out that Eran Hammer-Lahav criticises
> the ars.technica article at
> http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/
> but does mention that "there is no solution [...] for a distributed
> application" - does that mean OAuth isn't fit for FOSS?
>
> Hope that helps,
>