> 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)?
> 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.
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.
- 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?
Dirk.
