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."
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,
>> 4. What could we improve around the materials for integrating OAuth
>> into your application?
>> We really appreciate your feedback.
>> Best, Ryan