Speaking as a developer... On Mon, Oct 12, 2009 at 1:01 PM, Ryan Sarver <rsar...@twitter.com> wrote: > > 1. What can be improved about the web workflow?
The desktop OAuth flow is pretty good, but the mobile device OAuth flow is terribly painful. Since Twitter is very mobile focused, having smooth OAuth flows on as many mobile devices as possible is a win-win for devs and Twitter. This issue has a lot of interest from other devs as well: http://code.google.com/p/twitter-api/issues/detail?id=395 (I completely forgot that I submitted that issue). I know there are many mobile app developers that want to stay as far away from OAuth as possible at the moment. Many are still begging for Basic Auth source app keys citing that "mobile OAuth provides unacceptable UX for my app." > 2. What can be improved about the desktop workflow? n/a (for me) > 3. What other models of distributed auth do you think we could learn > from and what specifically about them? I am happy to see username/password Basic Auth go away, but I would be sad to see all methods of Basic Auth unavailable. Lots of other APIs have "api keys" that users can use to allow access to an api on their behalf (FriendFeed, Prowl, TweetHook, and some others come to mind immediately). Each user gets an API Key which allows manipulation of some aspects of their accounts, but as much as knowing the actual account password combo. This has a couple of advantages of Basic Auth and OAuth: a) If an app starts acting up, the user can revoke/change their account API key and just update the services that are still relevant to them to continue working. This isn't quite as nice as "per app" revokation that OAuth provides, but less "painful" from a user point-of-view as changing their account login password. b) Basic Auth is still possible. This means that simple use-cases like command-line curls, cron jobs, embedded systems, web-browser-less systems, etc can still interact with the API without having to jump through the OAuth hoops. I would suggest that "API Key Auth" should be required to use HTTPS and disable HTTP access. my 2 cents, -Chad > 4. What could we improve around the materials for integrating OAuth > into your application? > > We really appreciate your feedback. > > Best, Ryan >