I want to let gadgets specify whether to use OAuth(access_token) for
the owner or the viewer
Let's say i want to imlement a gadget that a viewer centric. and,
assume that
G : Gadget showing contents from a service provider that support
Oauth.
O : The owner of G
V : A viewer of G
if V goes to O's profile with G. viewer should see V's contents. But
it is not clear that a gadget users acces_token of
V according to Opensocial 0.8.
It will be better to be able to specify usering a viewer’s access
token when gadget.io.makeRequest is invoked.
Currently only the owners access token can be used. The enhancement you propose sounds like a great idea. Can you add some additional detail?
- what are the new parameters to makeRequest, and how are they interpreted by the server? - how should the gadget rendering server decide whether a particular user is allowed to use an OAuth access token issued to another user?
On Fri, May 16, 2008 at 3:53 AM, humbroll <humbr...@gmail.com> wrote:
> I want to let gadgets specify whether to use OAuth(access_token) for > the owner or the viewer > Let's say i want to imlement a gadget that a viewer centric. and, > assume that
> G : Gadget showing contents from a service provider that support > Oauth. > O : The owner of G > V : A viewer of G
> if V goes to O's profile with G. viewer should see V's contents. But > it is not clear that a gadget users acces_token of
> V according to Opensocial 0.8.
> It will be better to be able to specify usering a viewer's access > token when gadget.io.makeRequest is invoked.
Container proxy will interpret OAUTH_USER. and make an oauth request
to service provider with an access_token of either V or O.
> - how should the gadget rendering server decide whether a particular
> user is allowed to use an OAuth access token issued to another user?
i think it is matter of gadget implementation.
If makeRequest is invoked with V's access_token, there is no problem.
because V just does oauth authentication according to opensocial
specification.
however if makeRequest is invoked with O’s access_token, there is some
problem.
In this case, if V views O's profile, G has to behave according to
availability(meaning that exist and valid) of O’s access_token.
if the access_token is available, V can use gadget. otherwise, G is
unavailable to V.
On Tue, May 20, 2008 at 4:07 AM, humbroll <humbr...@gmail.com> wrote: >> - how should the gadget rendering server decide whether a particular >> user is allowed to use an OAuth access token issued to another user? > i think it is matter of gadget implementation. > If makeRequest is invoked with V's access_token, there is no problem. > because V just does oauth authentication according to opensocial > specification.
Let me see if I understand: both the viewer's and the owner's access tokens would be available to the gadget.
That's not backwards compatible with what we have today, where only the owner's access token is ever used. If someone has written a gadget that (for security reasons) depends on the viewers token not being usable, that gadget would become insecure by virtue of this change.
In general I'm suspicious of changes that are not backwards compatible.
Of course, using owners token is DEFAULT even viewer's access token
would be available.
And specifing "gadgets.io.RequestParameters.OAUTH_USER" is OPTIONAL.
That's backwards compitable i think.
Thanks for your feedback in advance.
On May 21, 3:59 am, "Brian Eaton" <bea...@google.com> wrote:
> On Tue, May 20, 2008 at 4:07 AM, humbroll <humbr...@gmail.com> wrote:
> >> - how should the gadget rendering server decide whether a particular
> >> user is allowed to use an OAuth access token issued to another user?
> > i think it is matter of gadget implementation.
> > If makeRequest is invoked with V's access_token, there is no problem.
> > because V just does oauth authentication according to opensocial
> > specification.
> Let me see if I understand: both the viewer's and the owner's access
> tokens would be available to the gadget.
> That's not backwards compatible with what we have today, where only
> the owner's access token is ever used. If someone has written a
> gadget that (for security reasons) depends on the viewers token not
> being usable, that gadget would become insecure by virtue of this
> change.
> In general I'm suspicious of changes that are not backwards compatible.
And V has Read Write, but O has only Read access with its role (viewer or owner) in the app.
how can you differenciate V acting as O and vice versa?
I think is possible to spoof a request using O access_token and make it Read Write. Unless u have 2 token for each User, one acting as V and other as O.
Is this possible? or i completely missed the point?
On Tue, May 20, 2008 at 10:56 PM, humbroll <humbr...@gmail.com> wrote:
> Of course, using owners token is DEFAULT even viewer's access token > would be available. > And specifing "gadgets.io.RequestParameters.OAUTH_USER" is OPTIONAL. > That's backwards compitable i think.
> Thanks for your feedback in advance.
> On May 21, 3:59 am, "Brian Eaton" <bea...@google.com> wrote: > > On Tue, May 20, 2008 at 4:07 AM, humbroll <humbr...@gmail.com> wrote: > > >> - how should the gadget rendering server decide whether a particular > > >> user is allowed to use an OAuth access token issued to another user? > > > i think it is matter of gadget implementation. > > > If makeRequest is invoked with V's access_token, there is no problem. > > > because V just does oauth authentication according to opensocial > > > specification.
> > Let me see if I understand: both the viewer's and the owner's access > > tokens would be available to the gadget.
> > That's not backwards compatible with what we have today, where only > > the owner's access token is ever used. If someone has written a > > gadget that (for security reasons) depends on the viewers token not > > being usable, that gadget would become insecure by virtue of this > > change.
> > In general I'm suspicious of changes that are not backwards compatible.
OAuth has no mechanism for describing a token as "read/write" or "read only". That's entirely up to the service provider. The gadget server (i.e. the OAuth proxy) cannot differentiate.
On Tue, May 20, 2008 at 7:55 PM, Ropu <rovagn...@gmail.com> wrote: > And this scenario?
> if V and O have the access_token
> And V has Read Write, but O has only Read access with its role (viewer or > owner) in the app.
> how can you differenciate V acting as O and vice versa?
> I think is possible to spoof a request using O access_token and make it Read > Write. Unless u have 2 token for each User, one acting as V and other as O.
> Is this possible? or i completely missed the point?
> Ropu
> On Tue, May 20, 2008 at 10:56 PM, humbroll <humbr...@gmail.com> wrote:
>> Of course, using owners token is DEFAULT even viewer's access token >> would be available. >> And specifing "gadgets.io.RequestParameters.OAUTH_USER" is OPTIONAL. >> That's backwards compitable i think.
>> Thanks for your feedback in advance.
>> On May 21, 3:59 am, "Brian Eaton" <bea...@google.com> wrote: >> > On Tue, May 20, 2008 at 4:07 AM, humbroll <humbr...@gmail.com> wrote: >> > >> - how should the gadget rendering server decide whether a particular >> > >> user is allowed to use an OAuth access token issued to another user? >> > > i think it is matter of gadget implementation. >> > > If makeRequest is invoked with V's access_token, there is no problem. >> > > because V just does oauth authentication according to opensocial >> > > specification.
>> > Let me see if I understand: both the viewer's and the owner's access >> > tokens would be available to the gadget.
>> > That's not backwards compatible with what we have today, where only >> > the owner's access token is ever used. If someone has written a >> > gadget that (for security reasons) depends on the viewers token not >> > being usable, that gadget would become insecure by virtue of this >> > change.
>> > In general I'm suspicious of changes that are not backwards compatible.
On Wed, May 21, 2008 at 1:39 PM, Brian Eaton <bea...@google.com> wrote:
> OAuth has no mechanism for describing a token as "read/write" or "read > only". That's entirely up to the service provider. The gadget server > (i.e. the OAuth proxy) cannot differentiate.
> On Tue, May 20, 2008 at 7:55 PM, Ropu <rovagn...@gmail.com> wrote: > > And this scenario?
> > if V and O have the access_token
> > And V has Read Write, but O has only Read access with its role (viewer or > > owner) in the app.
> > how can you differenciate V acting as O and vice versa?
> > I think is possible to spoof a request using O access_token and make it > Read > > Write. Unless u have 2 token for each User, one acting as V and other as > O.
> > Is this possible? or i completely missed the point?
> > Ropu
> > On Tue, May 20, 2008 at 10:56 PM, humbroll <humbr...@gmail.com> wrote:
> >> Of course, using owners token is DEFAULT even viewer's access token > >> would be available. > >> And specifing "gadgets.io.RequestParameters.OAUTH_USER" is OPTIONAL. > >> That's backwards compitable i think.
> >> Thanks for your feedback in advance.
> >> On May 21, 3:59 am, "Brian Eaton" <bea...@google.com> wrote: > >> > On Tue, May 20, 2008 at 4:07 AM, humbroll <humbr...@gmail.com> wrote: > >> > >> - how should the gadget rendering server decide whether a > particular > >> > >> user is allowed to use an OAuth access token issued to another > user? > >> > > i think it is matter of gadget implementation. > >> > > If makeRequest is invoked with V's access_token, there is no > problem. > >> > > because V just does oauth authentication according to opensocial > >> > > specification.
> >> > Let me see if I understand: both the viewer's and the owner's access > >> > tokens would be available to the gadget.
> >> > That's not backwards compatible with what we have today, where only > >> > the owner's access token is ever used. If someone has written a > >> > gadget that (for security reasons) depends on the viewers token not > >> > being usable, that gadget would become insecure by virtue of this > >> > change.
> >> > In general I'm suspicious of changes that are not backwards > compatible.
On Wed, May 21, 2008 at 9:53 AM, Ropu <rovagn...@gmail.com> wrote: > when i say read or read/write is in the logic of the gadget.
> and since aouth connot differentiate (except having 2 different tokens) we > can have the security issue i described.
> ropu
> On Wed, May 21, 2008 at 1:39 PM, Brian Eaton <bea...@google.com> wrote:
>> OAuth has no mechanism for describing a token as "read/write" or "read >> only". That's entirely up to the service provider. The gadget server >> (i.e. the OAuth proxy) cannot differentiate.
>> On Tue, May 20, 2008 at 7:55 PM, Ropu <rovagn...@gmail.com> wrote: >> > And this scenario?
>> > if V and O have the access_token
>> > And V has Read Write, but O has only Read access with its role (viewer >> > or >> > owner) in the app.
>> > how can you differenciate V acting as O and vice versa?
>> > I think is possible to spoof a request using O access_token and make it >> > Read >> > Write. Unless u have 2 token for each User, one acting as V and other as >> > O.
>> > Is this possible? or i completely missed the point?
>> > Ropu
>> > On Tue, May 20, 2008 at 10:56 PM, humbroll <humbr...@gmail.com> wrote:
>> >> Of course, using owners token is DEFAULT even viewer's access token >> >> would be available. >> >> And specifing "gadgets.io.RequestParameters.OAUTH_USER" is OPTIONAL. >> >> That's backwards compitable i think.
>> >> Thanks for your feedback in advance.
>> >> On May 21, 3:59 am, "Brian Eaton" <bea...@google.com> wrote: >> >> > On Tue, May 20, 2008 at 4:07 AM, humbroll <humbr...@gmail.com> wrote: >> >> > >> - how should the gadget rendering server decide whether a >> >> > >> particular >> >> > >> user is allowed to use an OAuth access token issued to another >> >> > >> user? >> >> > > i think it is matter of gadget implementation. >> >> > > If makeRequest is invoked with V's access_token, there is no >> >> > > problem. >> >> > > because V just does oauth authentication according to opensocial >> >> > > specification.
>> >> > Let me see if I understand: both the viewer's and the owner's access >> >> > tokens would be available to the gadget.
>> >> > That's not backwards compatible with what we have today, where only >> >> > the owner's access token is ever used. If someone has written a >> >> > gadget that (for security reasons) depends on the viewers token not >> >> > being usable, that gadget would become insecure by virtue of this >> >> > change.
>> >> > In general I'm suspicious of changes that are not backwards >> >> > compatible.
On Tue, May 20, 2008 at 8:59 PM, Brian Eaton <bea...@google.com> wrote:
> On Tue, May 20, 2008 at 4:07 AM, humbroll <humbr...@gmail.com> wrote: > >> - how should the gadget rendering server decide whether a particular > >> user is allowed to use an OAuth access token issued to another user? > > i think it is matter of gadget implementation. > > If makeRequest is invoked with V's access_token, there is no problem. > > because V just does oauth authentication according to opensocial > > specification.
> Let me see if I understand: both the viewer's and the owner's access > tokens would be available to the gadget.
> That's not backwards compatible with what we have today, where only > the owner's access token is ever used. If someone has written a > gadget that (for security reasons) depends on the viewers token not > being usable, that gadget would become insecure by virtue of this > change.
I'm not sure how the viewer's access token being usable to the gadget can be a security risk. When the gadget is not designed to use the viewer's token, the only one who can take advantage of the token being exposed is the viewer. So the viewer can control his own access token, which seems fine, doesn't it?
(alternatively he can install the gadget on his own profile, and be the owner and that way have access to the same token)
