Providing an API endpoint for basic auth credential exchange for a token would be a nice solution, but I can see it getting abused. An attacker could bombard this endpoint trying to guess an account's password. Protection can be placed to limit calls to this endpoint by IP which might be enough to prevent this kind of brute attack.
This has been brought up before on the oauth mailing list, but a lot of security folks cringe at the idea. I feel there is not much of a security loss here since the application running on the user's computer can already do harm. I'd like to hear from the Twitter API team on their thoughts of this idea. It might not be part of the spec, but OAuth is pretty open to service providers extending it. Josh On Mon, Oct 12, 2009 at 4:44 PM, Sebastian <sdelm...@gmail.com> wrote: > > The solution for OAuth on Mobile and Desktop is easy: > > Allow the app to act as the user agent when authenticating with > Twitter when requesting the token and authorizing the app. > > Let me rewrite this in plain english: let the app ask for login/ > password and pass it to twitter. > > Users don't seem to be worried about providing their credentials to a > "local" app. They do it all the time when configuring basic auth > clients, and they do it with 99% of the other client apps they use. > > Developers are (barely, in most cases) worried about having to store > the password, but if they only need it during the initial handshake, > then there is nothing to store. > > All we need is a simple API call where we can trade a login and > password for an oauth access token, bypassing the browser. > > And if you think this will make it less secure, think about a desktop > app that, using the current workflow, launches a browser to get the > user to approve the app. That browser can be configured to use local > proxies, or JS callbacks or any number of mechanisms that let the app > capture the authentication credentials. Getting rid of the browser has > no negative impact on safety, while giving developers better control > of the UX, which gives them more reasons to implement oauth, which > does have a positive impact. > > Anyway, just my two cents. > > PS: There is nothing right now preventing a mobile or desktop app from > bypassing the browser as I'm describing, by "acting as a browser" and > calling the same pages a browser would have presented to the user. > > On Oct 12, 1:01 pm, Ryan Sarver <rsar...@twitter.com> wrote: >> Hey everyone, >> >> I wanted to email the list to start gathering some feedback on how we >> can improve the OAuth workflow. As we have discussed in the past, >> Basic Auth is going to be deprecated at some point in the future for >> OAuth and we want to make sure we improve the experience to meet >> everyone's needs. I am interested in capturing feedback for both the >> web and desktop workflows. >> >> 1. What can be improved about the web workflow? >> 2. What can be improved about the desktop workflow? >> 3. What other models of distributed auth do you think we could learn >> from and what specifically about them? >> 4. What could we improve around the materials for integrating OAuth >> into your application? >> >> We really appreciate your feedback. >> >> Best, Ryan -- Josh
