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 -~----------~----~----~----~------~----~------~--~---
