> 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. >
Storing the request token in the session is unlikely to cause any problems. The worst possible outcome is that in an attack scenario the victim would be redirected to the consumer and the consumer wouldn't be able to find the request token since it's not in the victim's session. In this case the request token isn't really "bound" (at least not in a bad way) to the attacker. It's just persisted in a place that is only visible to one user. I'm not saying this is a good idea (I can think of some minor security implications), but it's not a huge deal either. The "bad" sort of binding would occur if the consumer associated a request token with a user pre-authorization, and completely ignored the user who returns to the site post-authorization. This requires additional effort since, instead of simply persisting the request token, you have to persist the request token along with some relation to a specific user of your system. 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. > I don't see how it would prevent the consumer from associating a user with the request token. In the end, the consumer application has to be responsible for persisting the request token somewhere, and retrieving it later. As long as that's true there's nothing stopping the consumer from associating the request token with a particular user of the system (aside from the fact that it's harder to do and wrong). 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 -~----------~----~----~----~------~----~------~--~---
