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