[OAUTH-WG] Use Cases for Signed Tokens

[Justin Richer <[e-mail]>]

I'd like to present two use cases for signed tokens, for input into the 
ongoing MAC/HoK/higher-security discussion. Both of these are actual 
cases that I've done in the past, and we've used either OAuth 1 or JW* 
to solve them. I think that with the right tooling, a MAC-token-like 
thing could be used here. I'll note to the crypto nerds in the group 
(ahem, John) that I'm going to be using terms like "signing" and "MAC" 
in a somewhat loose sense, so please don't get hung up on that because I 
think you actually know what I mean.

So:

1) Message-level signing.

In this, you protect the content of the HTTP message by signing it with 
the secret part of the token, effectively what was done in OpenID 2, 
OAuth1, and the MAC draft. You pick some subset of the HTTP components, 
add them to your signing base in a predictable and repeatable fashion, 
and sign it with your secret. You then send the signature along with all 
of the bare HTTP elements across the wire, and the far side does the 
same signature generation magic and you're good to go.

The driving use case to this is security in depth. Yes, you probably 
still do want everything to go over TLS, but that only protects things 
in transit between endpoints. It won't protect anything as it gets 
chewed through an application platform or handed around a server farm. 
It's also considered "best practice" in many cases. In my experience in 
the health care space, you almost always want to have multiple layers 
protecting you.

An alternative approach here is to use a JW* container like a JWS or JWE 
to hold all of your parameters (as claims) and sign/encrypt over that. 
But if you do that, you're not really using HTTP anymore, except as a 
dumb transport. This is the approach of SOAP, and I doubt that many will 
come to its defense. (At least, those that don't want to sell you 
something to process SOAP messages.) We've done this ourselves with a 
prototype, and losing all of the processing capability that comes with 
HTTP is a huge programmatic hit.

2) Signed URL as an authorized artifact.

In this, you have party A generate a URL with parameters in it, 
protected by a signature. That URL points to party B, who can validate 
the signature. Party A then hands that fully baked URL to a third party, 
C, who can't do anything to the parameters in the URL without messing up 
the signature. From party B's perspective, so long as that signature is 
valid, all the parameters in the URL can be trusted and the request can 
proceed. With a timestamp and nonce parameter (built in to OAuth1), 
you've even got really nice replay and timeout protection. TLS doesn't 
do you any good here, because there's a party in the middle who has the 
full right to hold and view the artifact (URL), but does not have the 
right to modify it. We've solved this in the past using OAuth1's 
signature mechanism without tokens (aka, 2-legged OAuth1). We can't 
currently do this with OAuth2. If we had a generalizable HTTP components 
signing mechanism (which MAC *almost* is, and could become), then we could.

Again, you could simply cram everything into a JW* container and send 
*that* as the sole parameter to a URL and get almost the same result. 
But then you've got to unpack that JW* container to get all of your 
parameters, and you're back in SOAP land. And again I posit: nerds hate 
SOAP.



Hopefully both of these will help inform the discussion and shed some 
light onto why I think that:
  * MAC tokens (or equivalent) are still a good idea for the WG to pursue
  * Channel-binding and TLS don't solve all security problems
  * Abusing JOSE leads to breaking good HTTP designs

  -- Justin