Oauth and (lack) delegation

[Michael Steuer]

Does Twitter (or anyone else) have thoughts around the lack of delegation in Oauth and the announced deprecation of basic authentication? Currently, to enable an API that allows web services to interact with Twitter on its behalf (e.g. TwitPic, yFrog, etc.) one has to rely on basic authentication (the twitter client passing the user’s username & password to the web services API), as delegation is not possible via Oauth... If a user authenticates with my application via Oauth, there’s no way I can have a 3rd party API do anything on behalf of that user...

Similarly, if I want to develop an API to my Twitter web service, I would have to develop that with basic authentication, but what’s the point:

• knowing that basic auth is going to be deprecated in the (near) future
• so many apps are now based on oauth and wouldn’t be able to use my API because they can’t authenticate
  

I’m sure other devs have run into this. Does Twitter have any thoughts around this? How do you expect to maintain a 3rd party app/API eco system after basic auth deprecation?

Looking forward to everyone’s feedback..

[Marcel Molina]

We've got a project lined up to come up with an answer for OAuth app
delegation problem. We haven't done a deep dive into what the approach
might be yet so we don't have any ideas yet. Would be glad to have the
conversation with those who are interested and have ideas.

--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio

[Michael Steuer]

Hey Marcel,

Good to hear Twitter is thinking about this issue. It sounds like timing is
kind of open ended at this point? I would obviously love to be part of the
conversation and help test things out etc. I did find a couple interesting
discussions/ideas while researching this issue, that you may or may not yet
be aware of:

http://groups.google.com/group/oauth/browse_thread/thread/bdf8b99e84a8aaef/7
7409186172e23ba?#77409186172e23ba

http://hueniverse.com/2009/03/taking-oauth-beyond-the-3rd-leg/

From my perspective, and I'm not a security expert, oauth expert or any
other kind of relevant expert, I could imagine a workflow where an app can
request a one-time-use-only token from Twitter that it can pass on to
another 3rd party app for one time use. So, for example, you have a Twitter
client, let's call it Tweetie, and a 3rd party service with API, let's call
it TwitPic (I'm not related to either)...

- Tweetie requests a one-time token from Twitter. The one-time token is
restricted to the user it is requested for, and the application it is
requested for.
- Tweetie performs an API request to TwitPic, passing on the one-time token.
- In turn, TwitPic can perform an API request to Twitter on behalf of the
Tweetie user (e.g. Post a picture), using the one-time token as an
additional oauth parameter.

One-time tokens are expired upon use or within X minutes after been granted.
A new one-time-token for a App1/App2/User combination cannot be granted
until an earlier granted token has either expired or been used. And since
such one-time tokens are specific to Requesting App, Receiving App and the
User, abuse is not likely as any of the 3 parties could restrict one of the
other 2 parties from requesting or receiving a token... Also, since both the
Requesting App and Receiving App are tied to the token, Twitter can display
a combined client attribute with the resulting tweets (e.g. "1 minute ago
from Tweetie via TwitPic")

Anyway - I'm sure there are plenty of drawbacks, other concerns or things
I'm overlooking - but just wanted to get the conversation started...

What other, perhaps equally high level options has Twitter or anyone else
come up with?

Thanks,

Michael.