On 8 Apr 2011, at 07:40, Jean-Noël Colin wrote: > Hi Scott, > > We're together with Tien wondering about the notion of widget instance and > that of a session. > > A widget instance is identified by the idkey, which is specific for an api > key, shared data key, widget id, user id. This means that if I can get hold > of the idkey, I can access the widget instance, even from outside the > original environment. > > If we think of widgets that give access to privileged services, like access > to the iTec registries, this becomes a security problem, because if my idkey > gets stolen, someone else could pretend being me.
To be honest I'm torn between thinking of this as a bug or a feature. > One way to solve this would be to go beyond the widget instance, and have a > notion of session, which means that even if someone else gets my idkey, he > would still appear as a different session; if oauth tokens are managed on the > basis of a session, then, stealing my idkey would not compromise access to > the services. > > Of course, this poses the issue of token management. > > We are thinking of different solutions: one would be to use one-time idkey, > rather than permanent one, so that if an idkey gets stolen, nothing gets > compromised. So basically, the idea is to integrate the notion of session or > to have a one-time handle to widget instances, renewed on every request. > > What do you think about this? Does it make sense? I think these sound like interesting ideas - however can we have the best of both worlds? Widgets that are simple to embed outside their original context, but still protect user's privileged service access? > > Cheers > > --- > Jean-Noël >
