specify OAuth for the viewer or the owner, in gadgets.io.makeRequest

[humbroll]

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.

Thanks for your feedback in advance.

[Brian Eaton]

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?

[humbroll]

> - what are the new parameters to makeRequest,

gadgets.io.RequestParameters.OAUTH_USER =
opensocial.DataRequest.PersonId.VIEWER |
opensocial.DataRequest.PersonId.OWNER
( specify in http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.PersonId.html)

>and how are they interpreted by the server?

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.

thanks.:)

[Brian Eaton]

On Tue, May 20, 2008 at 4:07 AM, humbroll <humb...@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.

Cheers,
Brian

[humbroll]

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:

[Ropu]

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

--
.-. --- .--. ..-
R o p u

[Brian Eaton]

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.

[Ropu]

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

[Brian Eaton]

That security issue can't be solved in the gadget, or in the OAuth
proxy. The service provider has to be able to issue tokens with
appropriate powers.

[Reinoud Elhorst]

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)
 

[Ropu]

as i see, the issue is not with the viewer token, but with the owner one

that token can be abused by the viewer

[Brian Eaton]

I haven't been able to think of a way to abuse the viewer token
either. So this sounds OK to me.

[Paul Walker]

I want to make sure I am following this as well.  I do see an issue if a separate token is used for owner or viewer w/out the context of the app id, in which a viewer could forge a makeRequest using another user’s owner token or their own viewer token to an app they don’t typically have.  This shouldn’t be an issue if the app id is part of the data in the encrypted token and both ids are verified.

 

Am I missing something here?

[Brian Eaton]

Yeah, this is an important policy issue. Do these policy guidelines make sense?

- OAuth access tokens are owned by the combination of
container/application/user, with the service provider having the power
to revoke the token at any time as well.
- access tokens may only be approved on pages where the owner and the
viewer are the same
- applications only get to use access tokens that were issued to them,
not to other applications
- applications may use the access token of either the owner or the viewer

(Only the last one is a change from the status quo, in Shindig at
least. Shindig currently only allows the access token of the owner to
be used.)

Cheers,
Brian

[Louis Ryan]

Does it make sense to provide scoping rules for application access to the tokens? Can I as an owner stipulate that a token which I generate is/is not accessible to viewers. I can certainly see cases where owners have two access tokens, one accessible to viewers and one only to themselves.

[Ropu]

I think that will be the only way to separate access with OAuth, one token for each access type...

The question is if oauth can create those 2 tokens in one single request to avid the owner to duplicate token requests.

As far as i see in the spec is not possible to exchange one request_token for two access_tokens with 2 different "roles"

ropu

[Brian Eaton]

On Thu, May 22, 2008 at 10:13 AM, Louis Ryan <lr...@google.com> wrote:
> Does it make sense to provide scoping rules for application access to the
> tokens? Can I as an owner stipulate that a token which I generate is/is not
> accessible to viewers. I can certainly see cases where owners have two
> access tokens, one accessible to viewers and one only to themselves.

Scoping rules of some type make sense, but the complexity worries me.
How are we going to explain to people that we are putting access
controls in a gadget server that apply to access tokens to some third
party site?

I'd like to see some really good use cases before we went this route.

[Brian Eaton]

On Thu, May 22, 2008 at 11:09 AM, Ropu <rova...@gmail.com> wrote:
> I think that will be the only way to separate access with OAuth, one token
> for each access type...
>
> The question is if oauth can create those 2 tokens in one single request to
> avid the owner to duplicate token requests.
>
> As far as i see in the spec is not possible to exchange one request_token
> for two access_tokens with 2 different "roles"

Definitely not possible with the current specification. We could
write an OAuth extension, but why would service providers support it?

[Dirk Balfanz]

Jumping in late here...

If I understand correctly, the argument is that if Alice can view
Bob's page, then Bob can always view Alice's page. So whatever data
we're trying to keep away from Bob by letting the gadget not have
access to Alice's token when she views his page - Bob can easily
access that data by simply going to Alice's page. So there is no
reason to withhold the viewer's token from a gadget, hence any gadget
that has access to the owner's token might as well be given access to
the viewer's token. Did I get that right?

Note that the reverse isn't true: a gadget that for some reason _only_
should be given access to the viewer's token shouldn't also
automatically have access to the owner's token.

I would like to point out that using the viewer's access token
(instead of the owner's access token) is only a special case of
allowing gadgets to use _arbitrary_ users' tokens (say, one of the
owner's friends). I'd like to see us solving this problem in the
general case (i.e. let the gadget ask for anyone's token and have an
access control story that goes with that), which would allow secure
gadget-side mash-ups.

Dirk.

On Thu, May 22, 2008 at 9:44 AM, Brian Eaton <bea...@google.com> wrote:
>

[Brian Eaton]

On Mon, May 26, 2008 at 11:49 PM, Dirk Balfanz <dirk.b...@gmail.com> wrote:
> If I understand correctly, the argument is that if Alice can view
> Bob's page, then Bob can always view Alice's page. So whatever data
> we're trying to keep away from Bob by letting the gadget not have
> access to Alice's token when she views his page - Bob can easily
> access that data by simply going to Alice's page. So there is no
> reason to withhold the viewer's token from a gadget, hence any gadget
> that has access to the owner's token might as well be given access to
> the viewer's token. Did I get that right?

Hrm. Not sure. You're assuming that because a gadget is on an
owner's page, the owner has control of the gadget. That's not true
today.

> Note that the reverse isn't true: a gadget that for some reason _only_
> should be given access to the viewer's token shouldn't also
> automatically have access to the owner's token.

This I agree with completely. Oddly enough, our initial spec said the
owner's token is always available, because there were interesting apps
you could build based on that rule. I'm not inclined to back away
from the "owner's token is always available" rule until somebody
discovers an interesting use case for it.

> I would like to point out that using the viewer's access token
> (instead of the owner's access token) is only a special case of
> allowing gadgets to use _arbitrary_ users' tokens (say, one of the
> owner's friends). I'd like to see us solving this problem in the
> general case (i.e. let the gadget ask for anyone's token and have an
> access control story that goes with that), which would allow secure
> gadget-side mash-ups.

I'm worried about the complexity of that access control scheme vs the
functionality it gives.

[Dirk Balfanz]

On Tue, May 27, 2008 at 11:29 AM, Brian Eaton <bea...@google.com> wrote:
>
> On Mon, May 26, 2008 at 11:49 PM, Dirk Balfanz <dirk.b...@gmail.com> wrote:
>> If I understand correctly, the argument is that if Alice can view
>> Bob's page, then Bob can always view Alice's page. So whatever data
>> we're trying to keep away from Bob by letting the gadget not have
>> access to Alice's token when she views his page - Bob can easily
>> access that data by simply going to Alice's page. So there is no
>> reason to withhold the viewer's token from a gadget, hence any gadget
>> that has access to the owner's token might as well be given access to
>> the viewer's token. Did I get that right?
>
> Hrm. Not sure. You're assuming that because a gadget is on an
> owner's page, the owner has control of the gadget. That's not true
> today.

Doesn't that depend on the container? But even without that assumption
- for the two principals involved (Alice and Bob), the data they can
see is exactly the same if (a) the gadget only has access to the pager
owner's tokens or (b) the gadget has access to both the page owner and
page viewer's tokens. Namely, they can see both Bob's and Alice's data
(because the friend relation is symmetric): In case (a), Alice has to
visit her own page to see her data, and Bob's to see his (and vice
versa), whereas in (b), Alice can see both users' data by going just
to Bob's page (and vice versa).

>> I would like to point out that using the viewer's access token
>> (instead of the owner's access token) is only a special case of
>> allowing gadgets to use _arbitrary_ users' tokens (say, one of the
>> owner's friends). I'd like to see us solving this problem in the
>> general case (i.e. let the gadget ask for anyone's token and have an
>> access control story that goes with that), which would allow secure
>> gadget-side mash-ups.
>
> I'm worried about the complexity of that access control scheme vs the
> functionality it gives.

Gadget-side mashups! What more in "functionality" do you want? :-)

Dirk.