The consumer should not be persisting the request token anyways. With the new spec the request token will be returned in the callback along with the oauth_verifier. Now the client call call the library to fetch the access token (ex. get_access_token(oauth_token, oauth_verifier)) and it returns back the access token.
On Thu, Apr 30, 2009 at 1:23 PM, Mike Malone <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
