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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
