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. On 11/5/09 4:55 PM, "Marcel Molina" <mar...@twitter.com> wrote: > > 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. > > On Thu, Nov 5, 2009 at 4:20 PM, Michael Steuer <mste...@gmail.com> wrote: >> 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.. > >
