ugh.. found typo in my response... this sentence should read: "Each user gets an API Key which allows manipulation of some aspects of their accounts, but *NOT* as much as knowing the actual account password combo."
-chad On Mon, Oct 12, 2009 at 1:37 PM, Chad Etzel <jazzyc...@gmail.com> wrote: > 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 >> >
