Ok but can I just confirm that the only way to do late binding is to have some parameter in the callback that identifies which Request Token was authorised/denied? Just want to make my understanding clear as there's nothing in the spec that says how this should be passed around (i.e. should it be oauth_token parameter sent on the query string of the callback, should this kind of thing be standardised? because really you want the SP to generate the callback parameters and not just take the oauth_callback verbatum as this could lead to a process just as easily worked around) O
2009/5/1 Josh Roesslein <[email protected]> > Agree this security issue does not apply to desktop clients. > > > On Thu, Apr 30, 2009 at 4:05 PM, Mike Malone <[email protected]> wrote: > >> For a desktop app you're typically binding the app to an account vs. >> binding a user of the app to an account. In this case you just need to make >> sure that the user who authorized the request token is the same user who is >> clicking "continue." This is what the oauth_verification "PIN" accomplishes. >> >> The situation is slightly different for web apps because a typical web app >> has more than one user, and can bind the access token to a different user >> than the one who returns after the authorization step. "Early binding" means >> the app is binding the request token to a particular user account before >> redirecting to the SP, then disregarding the user who returns after the >> authorization step and simply exchanging the request token for an access >> token bound to the same user account. >> >> Mike >> >> >> On Thu, Apr 30, 2009 at 1:48 PM, Owen Evans <[email protected]>wrote: >> >>> So can I ask, how do you not do early binding with desktop clients that >>> don't receive the call-back? >>> i.e. the only way of doing late binding is to identify via >>> the call-back url which request token was authorised or denied so that that >>> can be linked to the current user. If the application doesn't receive >>> the call-back and relies on the user to tell the application that the step >>> is complete there's no way of the application knowing which request token >>> was authorised and must have a link between the user and request token prior >>> to sending the user to the authorisation url? >>> >>> or am I missing something. >>> >>> Owen >>> >>> 2009/5/1 Mike Malone <[email protected]> >>> >>> On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein >>> <[email protected]>wrote: >>>> >>>>> Here is some pseudo python code of what I have in mind for a more >>>>> higher level library: http://pastie.org/464241 >>>>> >>>>> This is not a final design, there are other details I have left out, >>>>> but it demonstrates the flow for the consumer of authenticating with >>>>> oauth. >>>> >>>> >>>> Yea, that's pretty much what I had envisioned. And I counter: >>>> http://dpaste.com/39773/ >>>> >>>> As long as the consumer is tasked with persisting the request token >>>> you're not going to be able to do much to prevent early binding. And I >>>> still >>>> don't think there's much risk here anyways. In all the time I've been >>>> talking to people about OAuth I've never heard of anyone trying to do this >>>> (has anyone else?). There's just no reason to do it, and (I'll reiterate) >>>> it's harder than doing the right thing. >>>> >>>> Also, your DataStore code is very similar to the way the Python OAuth >>>> library manages tokens for SPs, and that code is the most confusing / least >>>> understood bit of the library (just had a conversation with Leah about just >>>> that). So I'm wary of requiring consumer developers (who have less at stake >>>> and are often less experienced) to do something that's already confusing >>>> developers on the SP side. >>>> >>>> >>>> Mike >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
