Raffi - can someone at Twitter PLEASE comment on the delegation question? If
your app uses the web oauth flow, as strongly recommended by Twitter and
reiterated in your statement below, how do you see consumption of 3rd party
APIs happening when you don't have the user's un/pw? I don't understand why
you're so unwilling to address that question?


On 12/10/09 7:42 AM, "Raffi Krikorian" <ra...@twitter.com> wrote:

> don't be evil.  in a web scenario, send them to twitter.com for the
> oauth workflow.  in the case that you can't do that, do not store the
> username and password - simply pass them through and store the tokens
> instead.
> 
>> @ michael
>> " The web case is different - a web site doesn't have the user's credentials
>> unless they explicitly provide them."
>> With the new  oAuth implementation even web apps will be allowed to collect
>> user's credentials. There is no way to enforce webapps to delegate
>> authentication
>> 
>> 
>> On Thu, Dec 10, 2009 at 8:42 PM, Michael Ekstrand <mich...@elehack.net>
>> wrote:
>>> 
>>> John Meyer wrote:
>>>> okay, forgive me if I'm wrong, but wasn't the whole point of oAuth
>>>> that the application didn't need to know the username/password?  That
>>>> the user would grant access to the application and then the
>>>> application would store that rather than the actual
>>>> username/password.  Or am I missing the point of going to an oAuth
>>>> system?
>>> Yes, that's the point of OAuth.  However, the dynamics of a web-based
>>> application vs. a desktop application complicate things.  If the user is
>>> trusting an application to run natively on their desktop, that
>>> application already has access to their username and password (it can
>>> read them from config files, do a keyboard grab when it spawns the
>>> browser, go snooping around in Firefox's memory space, any number of
>>> things).  Thus, in the desktop application case, allowing the user to
>>> input their username and password does not decrease security except
>>> perhaps by not always enforcing "don't give away your password".  The
>>> web case is different - a web site doesn't have the user's credentials
>>> unless they explicitly provide them.
>>> 
>>> I'm ignoring for the present sandboxed or sandboxable environments such
>>> as Java and AIR.  The runtime may prevent the local application from
>>> having access to the username/password as used by other applications.
>>> 
>>> - Michael
>>> 
>>> --
>>> mouse, n: A device for pointing at the xterm in which you want to type.
>>> Confused by the strange files?  I cryptographically sign my messages.
>>> For more information see <http://www.elehack.net/resources/gpg>.
>>> 
>>> 
>> 
>> 
> 
> 


Reply via email to