Sorry I forgot about the signing :). Maybe the library could provide a datastore interface which the consumer implements with their database. This way the library handles all the persisting of the tokens and secretes for the programmer. This makes it harder for the programmer to be tempted to prebind the token.
We can either try to hide the request token from the developer the best we can or make sure they are properly educated on how they should persist it (and not prebind). On Thu, Apr 30, 2009 at 1:40 PM, Jesse Myers <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
