John Panzer (http://abstractioneer.org)
On Mon, Jun 30, 2008 at 11:44 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote: > > You'd use two legged OAuth in case a third party client (not the JS API > > that > > has a security token) wants to talk to you. They don't have a security > > token because you they aren't your site, but they do have enough trust > (via > > out of band registration or other agreements) to let you let them make > two > > legged calls to you. > > > > So you're now saying that if you use a gadget security token then there is > no OAuth involved - not the normal OAuth (with an oauth_token), and not the > two-legged OAuth (with just a consumer_key)? Yes; the security token is an alternative to OAuth, and is currently only usable by the OpenSocial JS API. Is that different from what was discussed previously? > > > > > So perhaps: Prioritize OAuth first (in URL parameters and Authorization: > > header of course), if there are any oauth params then ignore st. Else, > > look > > for st and use that if possible. Else, error. > > > Ok, Take 2, then, on the proposal. How about this: There are two filters > for > authentication. First is an OAuth filter, second is a gadget-security-token > (GST) filter. > > - The OAuth filter does the following: > > > 1. if the incoming request is from a third-party-server that uses "full" > (as opposed to "two-legged") OAuth, then the request will > include an OAuth > token that identifies the user. We'll have an interface that will > allow > containers to map OAuth tokens to their native identities. The > principal > that will be represented to the servlets as "making the request" is > the > principal the OAuth token maps to. > > 2. if the incoming request is from a third-party-server that uses > "two-legged" OAuth (aka signedFetch), it won't include an OAuth > token. > Instead, it must include a xoauth_requestor_id parameter, which names > the > requester principal in a format native to the container. The > principal that > will be represented to the servlets as "making the request" is > the principal > identified in the xoauth_requestor_id. > Check, except that sometimes there is no xoauth_requestor_id and therefore no (user) principal. MySpace has this use case for example. I _think_ this just means that getUserPrincipal() should return null, Shindig code should be prepared to handle null, and containers that want to support this need to be prepared to handle null==getUserPrincipal(). > > > The principal making the request will be communicated to the servlets > through the getUserPrincipal() method in the HttpServletResponse. > getAuthType() will return "OAuth" in each case. > Great. > > > > - The GST filter then does the following: > 1. If the HttpServletRequest says that the request has already been > authenticated (getAuthType() != null) then it does nothing. > 2. Else, if the incoming request is from the container's own gadget > server, the request will include a gadget security token. The gadget > security token includes the owner and the viewer, expressed in > identities > native to the container. The GST filter validates the GST. The > principal > that will be represented to the servlets as "making the request" is > the > viewer. (If a gadget doesn't like that, it can make a raw OAuth > call to the > RESTful API server and use the token of the page owner, which > will then be > used according to point (1) in the OAuth filter explanation). > > The principal making the request will be communicated to the servlets > through the getUserPrincipal() method in the HttpServletResponse. > getAuthType() will return "GadgetSecurityToken" in this case. > > How's that? > LGTM > > Dirk. >
