On Oct 12, 11:44 pm, Josh Roesslein <jroessl...@gmail.com> wrote: > 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.
Your argument, while a valid concern, is moot. There is already a regular login page that can be abused just like you describe. It already has protection. Even regular API calls have to be protected because Basic Auth can be used for brute force attacks. Adding an api call to exchange login/password pairs for oauth tokens doesn't add any new security issues. It does open the possibility for web sites to use this call instead of the regular workflow, but, again, that possibility has always been there, doing automated calls to the regular login and auth pages. The only way to close that door is to offer web apps a way to do password-less authentication, which is what oauth does, and to train users to never ever give their password to a web site. But for non-browser, native apps (mobile, desktop, etc), forcing the use of a browser to authenticate to a separate website provides no security at all. The native app can easily intercept the http calls, the browser JS callbacks and many other ways to get that information. So there is no point in forcing this workflow. We're better off not giving users a false sense of security. > > 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
