OAuth support is on our to-do list, but it's far below providing more stability/QoS and a general cleanup the API.  
We're keeping our eyes on changes to the OAuth standard and we'll provide the most current support possible 
when we have time to work on our implementation.

(No comment was entered for this change.)

This is not only an enhancement but really a pretty major security issue. Recommend a
top priority.

Please!  I'd rather not have to encrypt and store twitter login info for my users.

Add another request for the priority of this to me lifted a bit higher.

I'd like to see this brought up in priority as well. Thanks!

Another vote from me!

Here here! Some form of API auth to replace using the user's credentials is sorely
needed.

Yes please add this soon!

Please implement this! It will be great.

+1 - This is a *huge* security issue.  Way more important than stability.

+1

+1

OAuth was recently discussed on twitter-development-talk:

http://groups.google.com/group/twitter-development-talk/msg/bfe3f7b5705717d2

On Nov-14-2008, Alex Payne (Twitter API lead) wrote:

{  Indeed, where my thinking is at is that we'll do the work necessary to
get beta OAuth support out there in our current stack, even if it does
mean some duplication of effort as we go forward.  As I said, Matt's
opinion was that the Rails OAuth plugin/library had improved to the
point where we wouldn't have to rework it.

If you have questions about our schedule and priorities, just ask.
There's no need to speculate.  I'm happy to be as open with you all as
I can possibly be about why and how we schedule our work, and what our
concerns and limitations are when implementing support for a new
technology.

I would strongly encourage a re-read of Christopher St John's posts is
this thread.  OAuth is simply a standardization of the token
authentication systems that several large companies were making use
of.  It's not a security silver bullet; token auth has a different
threat profile from BasicAuth, but not a non-existent threat profile.
At the end of the day, you can hand out your password or hand out a
token and you're still giving a potentially malicious application
rights to access your data.

OAuth's main benefit is that it decouples rights to API access from
general access to one's Twitter account.  It should also allow users
more granular control over which applications have what sort of rights
on their behalf.  That's good, and something our API and other APIs
that make use of BasicAuth sorely lack.

The downside is that OAuth suffers from many of the frustrating user
experience issues and phishing scenarios that OpenID does.  The
workflow of opening an application, being bounced to your browser,
having to login to twitter.com, approving the application, and then
bouncing back is going to be lost on many novice users, or used as a
means to phish them. Hopefully in time users will be educated,
particularly as OAuth becomes the standard way to do API
authentication.

Another downside is that OAuth is a hassle for developers.  BasicAuth
couldn't be simpler (heck, it's got "basic" in the name).  OAuth
requires a new set of tools.  Those tools are currently semi-mature,
but again, with time I'm confident they'll improve.  In the meantime,
OAuth will greatly increase the barrier to entry for the Twitter API,
something I'm not thrilled about.

Despite these downsides, we're pushing forward with OAuth, and we'll
keep you updated as to our progress.  }

Twitter must shift removal of the password anti-pattern to high priority

This is Matt's baby, so I'm assigning this issue to him.

Code is working and the changes from my performance review have been implemented. Working with the user 
experience team on making the sign-in flow usable.

Still working on UI usability and functionality. No major changes to underlying code from the feedback so far.

Launched admin only with a minor issue. That issue should be fixed today and we'll
keep testing. Expect to have the closed beta start this week.

Matt, you are awesome!

Moved into closed beta.

A few issues remain before closed beta completes.

closed beta completed, now in open beta. Closing the issue (at last) since we have
OAuth support. There are still issues to work on and no date has been set for turning
off Basic auth, hence the name 'beta' still being attached.