I think what you lose here is the atomic way people think about applications. Most users will consider each application completely separate, even if under the hood, they use each other's services.
EHL From: [email protected] [mailto:[email protected]] On Behalf Of Mike Malone Sent: Friday, March 27, 2009 9:53 AM To: [email protected] Subject: [oauth] Re: Is 4-legged OAuth possible? Yea, totally agree. You know where my loyalties lie wrt pragmatism & simplicity vs. "correctness." There are definitely a lot of issues to take into consideration here. I think the best approach to enumerating these issues, as you mentioned in your post, is to start with existing use cases and try to come up with some (preferably simple) mechanism to satisfy each use case using OAuth. Going back to the TweetDeck / TwitPic example, another possible solution would be to forget about delegating auth tokens, and instead provide some mechanism for third party apps to sync access tokens with one another. If TwitPic provided an endpoint that took a single signed URI to the Twitter API requesting the authorized user, it could verify that TweetDeck has auth'd said user and check whether that user is also a TwitPic user, passing that info back to TweetDeck. TweetDeck could then update its UI showing the photo option if the user has a TwitPic account, or a "sign up for TwitPic" link if they don't. TwitPic could then allow TweetDeck to post on the user's behalf. TweetDeck could pass along it's consumer key / access key with each request to TwitPic, which TwitPic could use to look up its own access token for that user. One problem with this type of approach: if the user revokes TweetDeck's token TweetDeck would still be able to make requests via TwitPic. Maybe TwitPic could periodically re-verify that the token is active? Or maybe it could pass along the consumer key and oauth token it's making requests on behalf of, and the provider could authorize that both tokens are still valid. Mike On Fri, Mar 27, 2009 at 9:02 AM, Eran Hammer-Lahav <[email protected]<mailto:[email protected]>> wrote: I agree and did repeat this warning in the post. The trick of course is to find a solution that is consistent with the simplicity of the OAuth design. The problem with a more limited "sub" token is that it might not be enough for the other application to perform its activities. EHL Some more thoughts on this topic at http://www.hueniverse.com/hueniverse/2009/03/more-thoughts-on-oauth-access-sharing.html From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Mike Malone Sent: Friday, March 27, 2009 12:57 AM To: [email protected]<mailto:[email protected]> Subject: [oauth] Re: Is 4-legged OAuth possible? Good post, Eran, but if you removed the token/consumer matching requirement entirely, and encouraged sharing token credentials, wouldn't we essentially be in the same boat we're currently in with usernames and passwords? (Ok, that may be a bit of an exaggeration, but we'd still be giving up a lot of what makes OAuth secure.) What if an application could request a limited use token (limited permissions, limited number of requests, limited lifetime, etc.) that it could then pass on to a third party application to make requests? Just a thought... Mike On Fri, Mar 27, 2009 at 12:28 AM, Eran Hammer-Lahav <[email protected]<mailto:[email protected]>> wrote: First, let's now get carried away with the leg count... I don't think naming this scenario 4-legged is helpful. I think your use case could be addressed in many way and the complexity level should be based on the actual threat model, not some generic "requirements". You'll notice that while section 6.3.2 (Core 1.0) explicitly requires that "The Request Token matches the Consumer Key", there is no such requirement in section 7. This means clients are free to share the token credentials with other clients if permitted by the server. This is a question of managing expectations more than anything else (when a user authorizes an application, they usually have an idea of what the application is going to do, including using other applications). I would encourage servers to permit token usage by clients other than those the tokens were issued to, only after explicitly obtaining permission for that from the client. While it would be great to have a way to keep the chain of control active for sharing access, services like Twitter might be just fine with just allowing tokens to be shared between applications. EHL More thought on my blog http://www.hueniverse.com/hueniverse/2009/03/taking-oauth-beyond-the-3rd-leg.html > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto:[email protected]<mailto:[email protected]>] On Behalf > Of Ivan Kirigin > Sent: Wednesday, March 25, 2009 9:14 AM > To: OAuth > Subject: [oauth] Is 4-legged OAuth possible? > > > Hi, > > I recently integrated Twitter's OAuth into my site, http://tipjoy.com > > It's a great user experience and a lot like Facebook Connect. > > But I ran into a problem when developing our API for Twitter > applications to use Tipjoy for payments. OAuth tokens aren't > transferable like a username & password. For example, a Twitter user > on TweetDeck can input a username & password, which lets TweetDeck > post a picture to TwitPic. If TweetDeck were granted OAuth access to > the user's Twitter account, TwitPic couldn't verify the access tokens > easily, and couldn't communicate to Twitter with them. > > How can we power this 4-legged OAuth? Twitter could act as an > intermediary, to tell TwitPic that the request from TweetDeck is > authorized. > > I'm told Facebook is coming up with a solution for Facebook Connect. > As the environment for social apps becomes more connected, this > communication between 3rd parties about users on the OAuth provider > become more important. > > What do you all think? > > Thanks, > Ivan > http://tipjoy.com > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
