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

Reply via email to