Subject: [OAUTH-WG] Understanding how OpenSocial uses OAuth 1.0a

From: David Recordon <[email-masked]>
Date: Tue, 16 Mar 2010 11:12:38 -0700

Kevin Marks has been bugging me for awhile to understand how
OpenSocial makes use of two-legged OAuth.  I reached out to the team
and here's their description (via Evan Gilbert).  In general it seems
like they're more making use of OAuth's RSA signature mechanism rather
than the user authorization and access token flows.

1. Developer (let's say iLike) creates a gadget that runs in multiple
containers.
2. User Bob is views iLike gadget on MySpace and the iLike gadget
needs to make a request back to iLike's home server to get private
data (let's say the user's favorite bands)
3. iLike gadget makes a JavaScript call to get this data from iLike
servers. This call uses a gadgets API (gadgets.io.makeRequest) that
proxies the request through MySpace servers.
4. MySpace adds validated URL parameters to the request - most
importantly opensocial_viewer_id and opensocial_app_url. MySpace then
signs the request and then forwards on the request to iLike's servers.
4.5 iLike can choose to sign request with MySpace's private key or
with a shared secret between iLike & MySpace.
6. iLike verifies the signed request, using MySpace's public key or
the shared secret.
7. iLike checks verifies opensocial_app_url to make sure this isn't a
different gadget asking for data.
8. Lastly iLike looks up user data based on opensocial_viewer_id and
returns it back to the gadget.

Intro to signed requests:
http://wiki.opensocial.org/index.php?title=Introduction_To_Signed_Requests
Validation of signed requests:
http://wiki.opensocial.org/index.php?title=Validating_Signed_Requests

---

From: Brian Eaton <[email-masked]>
Date: Tue, 16 Mar 2010 11:27:40 -0700

> than the user authorization and access token flows.

It's not just opensocial.  This is more or less what Microsoft is
doing with Simple Web Tokens, and there are some other Google use
cases as well.

Cheers,
Brian

---

From: Eric Sachs <[email-masked]>
Date: Tue, 16 Mar 2010 11:37:27 -0700

Here is one of the original writeups of OpenSocial + 2LO with a scanned
napkin drawing :-)

http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi

On Tue, Mar 16, 2010 at 11:12 AM, David Recordon <[email-masked]>wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Ethan Jewett <[email-masked]>
Date: Fri, 19 Mar 2010 13:52:22 -0400

I think 4.5 should read "iLike gadget can choose to sign request with
MySpace's private key or with a shared secret between iLike &
MySpace."

If I'm reading correctly, if the gadget chooses to use the container's
private key, then that is making use of the RSA signature mechanism.
If the gadget chooses to use the container's shared secret, then that
is the HMAC-SHA1 signature mechanism. It looks to me like the
PLAINTEXT method is not supported at all based on the wiki though I
don't see a technical reason why it should not be supported.

Ethan

---

From: Brian Eaton <[email-masked]>
Date: Fri, 19 Mar 2010 11:44:59 -0700

On Fri, Mar 19, 2010 at 10:52 AM, Ethan Jewett <[email-masked]> wrote:
> is the HMAC-SHA1 signature mechanism.

That's right.

> It looks to me like the

Plaintext doesn't work in this context, because it sends long-lived
secrets in clear-text to servers that are under the control of the
application author, or, in the case of gadgets, everyone viewing the
gadget.

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Fri, 19 Mar 2010 11:45:50 -0700

> application author, or, in the case of gadgets, everyone viewing the

Ah, the other reason plaintext doesn't work is because one of the
goals is to guarantee the integrity of the identity information passed
in the request - neither the application author nor the viewer of the
application is permitted to tamper with those parameters.

---

From: Ethan Jewett <[email-masked]>
Date: Fri, 19 Mar 2010 16:28:38 -0400

> application is permitted to tamper with those parameters.

I don't think so. In the OpenSocial case, the only "OAuth Consumer"
per se is the OpenSocial container. The gadget is not making signed
requests and is completely trusting the container to represent it
properly to the OAuth Provider. In other words, from an OAuth request
flow perspective, the gadget is pretty much irrelevant.

Because of this, on my reading OpenSocial gadgets will have a hard
time making use of general purpose APIs, because general purpose APIs
will ignore the opensocial_viewer_id parameter, which is the key to
figuring out what application user is making the request.

In other words, the gadget and the OAuth provider must completely
trust the OpenSocial container to correctly represent the user making
the request.

Am I reading it wrong?

Ethan

---

From: Ethan Jewett <[email-masked]>
Date: Fri, 19 Mar 2010 17:16:19 -0400

Accidentally sent the following directly to Brian instead of the list.
I'll try again ....

> application author, or, in the case of gadgets, everyone viewing the

That's not what I read. In the OpenSocial case the gadget does not
hold the secret as that would be insecure in the manner you describe.
The container holds the secret. The gadget only tells the container
what signing method to use, not what secret to use. How the container
manages to get the secret or keep track of which secret works with
which provider is a mystery to me.

There is not need to send the secret in the clear. OAuth 1.0a says
that the PLAINTEXT method should be used only over a secure channel.

Ethan

---

From: Brian Eaton <[email-masked]>
Date: Fri, 19 Mar 2010 15:21:19 -0700

> that the PLAINTEXT method should be used only over a secure channel.

The gadget tells the container *where* to send the request.  So if
OpenSocial gadgets supported PLAINTEXT, a malicious gadget author, or
a malicious user of a gadget (they are pure javascript) could tell the
container "please send a request to
https://www.example.com/log_my_secret".

And the container would then leak the secret to www.example.com.

Note that the encrypted channel doesn't help with this. =)

Also note that the OAuth signing is intended to authenticate the
opensocial_* and oauth_* parameters as having originated with the
container, not the gadget.  If you allow PLAINTEXT, that doesn't work
any longer either.

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Fri, 19 Mar 2010 15:24:54 -0700

> flow perspective, the gadget is pretty much irrelevant.

I think the opensocial use cases are interesting for two reasons.

1) They use signed identity claims.
    MS has done this with SWT.
    Lots of people have done this with OpenID and SAML.
    UMA is using signed tokens with identity claims.

2) They have trusted containers that do OAuth on behalf of applications.
    This is a powerful security tool - the gadgets get short-lived
access to data, the containers hold the long-lived secrets.  WRAP also
lets you do this.

Cheers,
Brian

---

From: Ethan Jewett <[email-masked]>
Date: Mon, 22 Mar 2010 18:03:35 -0400

> And the container would then leak the secret to www.example.com.

I've got to be missing something in the OpenSocial specification, but
in my mind the container *must* be keeping track of which secrets
belong to which domain, even for the signing case. Signing a request
to a random domain with a random secret isn't going to work, so the
application must be taking requests from gadgets and doing some
matching to secrets based on the URL. This matching (done correctly -
a big "if") should preclude leaking secrets.

In any case, this is probably neither here nor there. I agree with
your assessment of the two main interesting Open Social use cases.
Especially the idea that it is an example of a type of trusted
containers that can protect secrets from other applications or mediate
for an application in a not-as-highly-trusted environment.

Ethan

---

From: Brian Eaton <[email-masked]>
Date: Tue, 23 Mar 2010 11:30:08 -0700

> for an application in a not-as-highly-trusted environment.

Cool.  I'll reply off-list with the gnarly details of opensocial.

---

From: Kevin Marks <[email-masked]>
Date: Tue, 23 Mar 2010 11:45:46 -0700

The other related use case here is the Google Apps marketplace model for
sitewide app auth:

http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAuth

http://www.google.com/support/a/bin/answer.py?hl=en&answer=162105