I disagree with the sentiment that we should just dismiss "bad" developers who implement early binding.
I hadn't thought of late binding as the path of least resistance, so perhaps I'm making a bigger deal of this than I need to, although it occurs to me that some developers will be tempted to store the request token in the current session, which is really easy in most environments, and doesn't require any extra token-user binding implementation. I actually think there's a lot that good library implementations can do to help, but the simplest thing is to define a clean callback/interface for request token storage that does not reference users or sessions. Developers would have to go out of their way to use early binding, which as you say is not the path of least resistance. A good library could also define a callback/interface for access token storage that does reference users or sessions, but that's certainly more complicated because it gets into application logic. Jesse On Thu, Apr 30, 2009 at 10:29 AM, Mike Malone <[email protected]> wrote: > On Thu, Apr 30, 2009 at 10:12 AM, Jesse Myers <[email protected]> wrote: >> >> I can't say that I agree. > > What do you disagree with? Eran said early binding would be addressed in the > security considerations section. > >> The fact of the matter is that a lot of developers are going to >> encounter OAuth for the first time when they first need to integrate >> with an SP. Most developers will immediately download an OAuth library >> from somewhere and start to work with it. They probably won't read the >> OAuth spec and internalize it. If they do read the spec, they may just >> gloss over whatever disclaimer warns them off of early binding or not >> have any idea what early binding is. > > Early binding is also harder. Why would you try to maintain state > (user/request token binding) between requests when you don't have to? The > path of least resistance is the right one in this case, which should be > enough to keep most "bad developers" from screwing things up. > > I can't think of any way you'd be able to enforce this constraint in the > OAuth libraries short of not providing access to the request token. And > that's not really an option since the consumer app needs to persist the > request token somewhere, and the library has no way of knowing where that > somewhere is. > > 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 -~----------~----~----~----~------~----~------~--~---
