I'm not sure how this would work in practice. How would this flow be triggered by the iPhone app when it wants to post a photo to Twitter? And keep in mind that the user may or may not be involved at this point.
EHL > -----Original Message----- > From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf > Of Will Norris > Sent: Friday, March 27, 2009 9:35 AM > To: oauth@googlegroups.com > Subject: [oauth] Re: Is 4-legged OAuth possible? > > > Eran, > > After reading this thread and your two posts, another approach comes > to mind. In your second post, you talk about the primary application > actually obtaining the oauth token for the secondary application and > passing it along. But is that really necessary? All the primary > application needs to be able to do is authorize a request token on > behalf of the user which the secondary application has obtained. So > the flow would be something like: > > - normal OAuth flow with primary application. User grants > additional ability to the primary application to authorize additional > tokens on the users behalf. This could of course be limited as you've > described in your posts > > - secondary application gets a request token, but instead of having > the user authorize the token, the primary application authorizes the > token through some to-be-defined flow > > - this could work for tertiary applications in two ways. 1) the > secondary application grants the token for the tertiary application. > (But when/how was the secondary token granted access to authorize > other tokens?) 2) if the tertiary application knows who the primary > application is, it can request that the primary application authorize > the token > > > -will > > > On Mar 27, 2009, at 9:02 AM, Eran Hammer-Lahav 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: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On > > Behalf Of Mike Malone > > Sent: Friday, March 27, 2009 12:57 AM > > To: oauth@googlegroups.com > > 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 > <e...@hueniverse.com > > <mailto:e...@hueniverse.com>> 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: oauth@googlegroups.com<mailto:oauth@googlegroups.com> > [mailto:oauth@googlegroups.com > >> <mailto:oauth@googlegroups.com>] 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
