Apps that provide an API should implement their own API authentication scheme.
In all honesty, I do not think it should be Twitter's problem. An app can very easily provide the user with a unique API key, such as the one used by bit.ly and FriendFeed (initially), that your user must enter in your application for it to operate on the other app's API on behalf of your user. That means your user must authorize the API app to operate on her Twitter account, and depending on the nature of your app, do the same for your app as well. That makes sense. Piggy-backing your app off the authorization of another app does not makes sense. As far as the concern that existing Basic Auth apps suddenly have a strategic advantage over existing OAuth apps, the following: a) If it is true that 90% of all users prefer the convenience of a Basic Auth solution, then why are we forcing a more cumbersome solution down their throats? There will always be some form of Basic Auth in some of the apps. My app will always do its primary local site authentication via username and password, because I am not going to tie my user authentication to and depend on one external service. b) The proposed method makes migration of existing users to OAuth very easy because one can now simply run a one-time batch script to obtain the tokens from Twitter and replace the Twitter username and password with those tokens. For new users of your site, you can still follow the standard OAuth pin workflow without asking for their Twitter credentials, in order to obtain the tokens. c) Will some apps decide to continue to ask for Twitter credentials and obtain the tokens with this alternate method? Probably. But, the support load created by users changing their Twitter credentials without understanding the need to make the corresponding change in your app, makes the normal OAuth worklflow a far better solution. On Dec 10, 2:01 pm, Michael Steuer <mste...@gmail.com> wrote: > Great to hear it¹s on your radar and you¹re actively working on it. Any > chance you¹ll involve the dev community prior to presenting the solution as > a fait-accompli? And do you have an idea around timing for this solution? > > On 12/10/09 9:55 AM, "Raffi Krikorian" <ra...@twitter.com> wrote: > > > > > we're not unwilling to answer the question. it is something we're actively > > working on, and we're just not in a state to release anything yet. > > > On Thu, Dec 10, 2009 at 9:52 AM, Michael Steuer <mste...@gmail.com> wrote: > >> 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 > >>> <http://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>.
