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" 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 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..
>
>
