Here is some pseudo python code of what I have in mind for a more higher level library: http://pastie.org/464241
This is not a final design, there are other details I have left out, but it demonstrates the flow for the consumer of authenticating with oauth. On Thu, Apr 30, 2009 at 1:47 PM, Josh Roesslein <[email protected]>wrote: > 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 -~----------~----~----~----~------~----~------~--~---
