Doesn't the consumer still need to store the secret for the request token to sign the access token exchange? I didn't think the request token secret was in the callback.
On Thu, Apr 30, 2009 at 11:37 AM, Josh Roesslein <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
