Restful APIs: Security

[Paul Walker <pw...@myspace.com>]

I'd like to kick off a thread on Security of the OpenSocial RESTful APIs
in lieu of the desire to move forward with implementation (reference or
production).

I'll cut and paste the initial proposal's text on the matter:

/*************/
Authentication and Authorization
Requests use OAuth [OAuth.net] for authentication and authorization.
The container is the OAuth Service Provider and the client is the OAuth
Consumer.  Clients can use and pass in a full user-level authorization
token, using the full OAuth protocol.  Alternatively, if a client has a
trust relationship with a container, it can use "two legged" OAuth
authorization in which there is no user-based token.  (A "two legged"
use profile is being defined for within the OAuth working group.)

In each of these cases, the URL and auth[nz] data is signed by the OAuth
protocol.  Additional security can be obtained with SSL connections.

Clients may supply an OpenSocial-specific OAuth extension parameter,
x-oauth-os-uid, to identify the current user (the user who the client is
acting on behalf of).  The format of this parameter is the urn: GUID of
the current user, as supplied by the container to the client in an out
of band manner
/*************/

As well as some good questions Brian Eaton raised:

/*************/
- who (in real life) will the caller of the APIs be?  Are these gadget
home servers?  Consumers?  Somebody else?

- what permissions are the callers of the APIs intended to have?

- how will the container know to trust the caller of the APIs?

- how will keys be distributed?

- how will keys be changed?
/*************/

And end with sharing our current implementation at MySpace and my
thinking behind it.  

/*************/

We have identified three different security contexts against the MySpace
REST APIs and they are all in use in production currently.  

1. User-Agent JS Container to API XHR requests.  
	I hope one of the goals of this spec is that it will satisfy the
needs of the OS container JS :-).  In this context we use a token based
security approach in which the token represents the owner/viewer/app
id/timestamp.  The token is passed in XHR requests in a
X-OpenSocial-Token header.  

2. MySpace app server to server requests
	This is a request from a 3rd party server to our server signed
with OAuth in which the 3rd party has an application that exists on
MySpace.  This type of request happens for many different reasons but
the most common scenario is when an application uses an external iframe
on the canvas page where we supply them the owner/viewer ids and oauth
signature in the src attribute of the iframe the same as we do with
makeRequest.  The oauth_token is an empty string in this case as we
execute a conditional check on the service security layer that validates
the user for which the request is being made has the application
installed and has granted rights to that particular resource.  We
considered the concept of a request on "behalf of a user" similar to
John's text regarding an "x-oauth-os-uid" header or parameter, but after
an analysis of all of the use cases we decided that for the most part
the concept of viewer/owner did not really apply in these requests and
that the user as identified in the resource url had to have granted the
application permission to access the resource either by simple
installation of the app or by a specific app permission for the
resource.  

3. External app server to server requests 
	This context constitutes the requests that may be made by
external web site/desktop/device applications....the use cases well
outlined in the access delegation portion of the OAuth spec in which an
external application requires a session based oauth_token in order to
access a user's resources.  The token contains the context of the
user/application/timestamp/and any additional non-standard permissions
the application may require.  Some partners apps are able to skip the
first few steps and obtain the token directly if the user is logged in
as we will look for the auth cookie and provide them the token
immediately.  Some applications have longer lived tokens upon request
and the user is able to grant a pseudo permanent token upon
authentication if they choose "Don't ask me again" as well as manage the
tokens given to external applications within MySpace.  We have a demo of
this context on our developer site here:
http://developer.myspace.com/modules/apis/pages/accessdelegationtool.asp
x.

4. I said three didn't I?  We will be launching a fourth context mode
for JSONP request support.  Not sure this if this is appropriate for OS
discussion.

/*************/

Sorry for the long winded email.  I don't mean to posit this as what's
best for OpenSocial and look forward to the discussion.  Brian I hope
this begins to answer some of your questions from our thinking.  To add
a bit concerning your last two questions.  We plan to give apps new
shared secret keys and a window of time to allow them to switch over as
well as give external apps a method and window to swap the "pseudo
permanent" oauth_token values as we change encryptions keys.

~Paul

RE: Restful APIs: Security

[Paul Walker <pw...@myspace.com>]

This is simply an implementation of OAuth for session based
authentication for external applications.  

A typical step by step example that OAuth often talks about is a photo
printing site that would like access to a Service Provider.

This site would make a signed OAuth request in order to obtain an
unauthorized Request Token at http://api.myspace.com/request_token.  
It would then navigate the user to the authorization page at
http://api.myspace.com/authorization.  After the user authenticates and
grants the app permission they are then redirected back to the
oauth_callback URL (provided in the original request to the
authorization page).  The consumer handles this redirect and then
exchanges the Request token for a session based Access Token at:
http://api.myspace.com/access_token.  The consumer/external application
can now use this token as the oauth_token in API requests for the user.

There is a step by step example at: 
http://developer.myspace.com/Modules/APIs/Pages/AccessDelegationTool.asp
x

You must be logged in and have created an app on MySpace in order for
this to work.  You can create an app with gadget xml and choose amongst
your apps in order to kick off the example workflow.

~Paul

-----Original Message-----
From: opensocial-and-gadgets-spec@googlegroups.com
[mailto:opensocial-and-gadgets-spec@googlegroups.com] On Behalf Of Brian
Eaton
Sent: Tuesday, April 01, 2008 11:01 PM
To: opensocial-and-gadgets-spec@googlegroups.com
Cc: shindig-dev@incubator.apache.org
Subject: Re: Restful APIs: Security


On Tue, Apr 1, 2008 at 8:33 AM, Paul Walker <pw...@myspace.com> wrote:
>  3. External app server to server requests
>         This context constitutes the requests that may be made by
>  external web site/desktop/device applications....the use cases well
>  outlined in the access delegation portion of the OAuth spec in which
an
>  external application requires a session based oauth_token in order to
>  access a user's resources.  The token contains the context of the
>  user/application/timestamp/and any additional non-standard
permissions
>  the application may require.  Some partners apps are able to skip the
>  first few steps and obtain the token directly if the user is logged
in
>  as we will look for the auth cookie and provide them the token
>  immediately.  Some applications have longer lived tokens upon request
>  and the user is able to grant a pseudo permanent token upon
>  authentication if they choose "Don't ask me again" as well as manage
the
>  tokens given to external applications within MySpace.  We have a demo
of
>  this context on our developer site here:
>
http://developer.myspace.com/modules/apis/pages/accessdelegationtool.asp
>  x.

I've read this a few times, and I have to admit I still don't
understand it.  Would you be willing to break this down a little
further, maybe offer a step by step example?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to
opensocial-and-gadgets-spec@googlegroups.com
To unsubscribe from this group, send email to
opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Restful APIs: Security

[Brian Eaton <be...@google.com>]

On Tue, Apr 1, 2008 at 8:33 AM, Paul Walker <pw...@myspace.com> wrote:
>  3. External app server to server requests
>         This context constitutes the requests that may be made by
>  external web site/desktop/device applications....the use cases well
>  outlined in the access delegation portion of the OAuth spec in which an
>  external application requires a session based oauth_token in order to
>  access a user's resources.  The token contains the context of the
>  user/application/timestamp/and any additional non-standard permissions
>  the application may require.  Some partners apps are able to skip the
>  first few steps and obtain the token directly if the user is logged in
>  as we will look for the auth cookie and provide them the token
>  immediately.  Some applications have longer lived tokens upon request
>  and the user is able to grant a pseudo permanent token upon
>  authentication if they choose "Don't ask me again" as well as manage the
>  tokens given to external applications within MySpace.  We have a demo of
>  this context on our developer site here:
>  http://developer.myspace.com/modules/apis/pages/accessdelegationtool.asp
>  x.

I've read this a few times, and I have to admit I still don't
understand it.  Would you be willing to break this down a little
further, maybe offer a step by step example?