Re: [OAUTH-WG] Token Chaining Use Case

Justin Richer <> Tue, 07 July 2015 23:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F4D91A1A22 for <>; Tue, 7 Jul 2015 16:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R-5zadXwzWUU for <>; Tue, 7 Jul 2015 16:47:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7CED1A014C for <>; Tue, 7 Jul 2015 16:47:12 -0700 (PDT)
X-AuditID: 12074425-f799a6d000007db3-60-559c64ff9454
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 7B.34.32179.FF46C955; Tue, 7 Jul 2015 19:47:11 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t67NlAf6012960; Tue, 7 Jul 2015 19:47:10 -0400
Received: from artemisia.richer.local ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t67Nl8pT032346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jul 2015 19:47:09 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC5FD7A8-19AE-4DDA-892F-1FBE86DD1AA3"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Justin Richer <>
In-Reply-To: <>
Date: Tue, 7 Jul 2015 19:47:07 -0400
Message-Id: <>
References: <> <> <>
To: Mike Jones <>
X-Mailer: Apple Mail (2.2098)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6novs/ZU6owfYLghar/99ktNg77ROL xcm3r9gcmD2WLPnJ5NG64y+7x92jF1kCmKO4bFJSczLLUov07RK4Ml5ufshY8Og4Y8WxKYsZ Gxinr2DsYuTkkBAwkTjzeTUrhC0mceHeerYuRi4OIYHFTBJLZy+CcjYwStw9M48FwnnAJHFl /XGwFmaBBIk5z86BjeIV0JN49PQxO4gtLKAvsXx7H1gNm4CqxPQ1LUwgNqdAtMTT9m1gNSwC KhKTvqyHmhMr8an1DRPEHCuJtz2zGSGWnWOU+LD1E1hCREBH4vHFb0AncQDdKivxdavcBEaB WUjOmIXkDIi4tsSyha+ZIWxNif3dy1kwxTUkOr9NZF3AyLaKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI10IvN7NELzWldBMjOBZcVHcwTjikdIhRgINRiYf3Q+ScUCHWxLLiytxDjJIcTEqivF7J QCG+pPyUyozE4oz4otKc1OJDjBIczEoivAnuQDnelMTKqtSifJiUNAeLkjjvph98IUIC6Ykl qdmpqQWpRTBZGQ4OJQnemyBDBYtS01Mr0jJzShDSTBycIMN5gIY/SAIZXlyQmFucmQ6RP8Wo KCXOGwnSLACSyCjNg+uFpapXjOJArwjz7gOp4gGmObjuV0CDmYAGL9edBTK4JBEhJdXAOO16 5wwx4Y5z188WvjupnvT1xu2YPwLK5x0bd2yb22OxvPLjJEP5i4eSOoI5Zye2+Fn8Ofn/l+Cj k0bRatMjHHcE6fpOlPj7nmVrR01Z1fK3vDWvRcQinq8w4tMNnPp3I8eGZtPDoQp2dRpmH7Ls wzsWdj3Nz7HYpLZR9/q6HWIWLYxyM48kKrEUZyQaajEXFScCAOtUcHowAwAA
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] Token Chaining Use Case
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jul 2015 23:47:19 -0000

This approach is not a good fit for my use cases, and it’s still not  OAuth-y at all. It requires a specially-formed security assertion on the way in, which the client must understand and generate. I still can’t take an arbitrary token I’ve been handed by someone else and pass it off to be pushed forward. The new “*_type” parameters seem to merely kick the can down the road instead of addressing the problems with the current specification.

I think that Brian’s approach works much better. It unrolls important parameters, properly uses the token endpoint, and allows for arbitrarily formatted input tokens. 

When combined with Nat’s draft that specifies how to perform all generic OAuth requests as JWTs (or even some of the upcoming PoP work if we ever do that), you’ve pretty much got the draft below but with much more flexibility and power. 

 — Justin

> On Jul 7, 2015, at 6:51 PM, Mike Jones <> wrote:
> As just updated <>, I believe that the working group token exchange draft <> can now also serve the “OAuthy” token exchange use cases, such as Justin and Phil’s token chaining use case, as well as support general token exchange, including exchange of JWT and SAML tokens.  The mechanism would be the same one that Brian suggested below – defining security token type values for OAuth 2.0 access tokens and refresh tokens – enabling them to be used as inputs and outputs in any of the token exchanges.
> For instance, by using “access token” as the input security token type, providing new scope values, and using “access token” as the output security token type, token chaining is achieved.
> Now, a question for the working group…  What should the security token type values for access token and refresh token be?  Two different choices seem to make sense.
> (1)  Use the values “access_token” and “refresh_token”, which are used in RFC 6749 token response values.
> (2)  Define new URNs for this usage, such as urn:ietf:params:oauth:token-type:access-token and urn:ietf:params:oauth:token-type:refresh-token.
> I’d personally be fine just using the short names in (1).
> If people agree with this approach, we can document this usage in the -03 draft and publish it as soon as the submission tool reopens Monday morning during IETF 93.
>                                                                 -- Mike
> From: OAuth [] On Behalf Of Brian Campbell
> Sent: Thursday, March 26, 2015 3:15 PM
> To: Justin Richer
> Cc: <>
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
> This kind of token exchange might involve exchanges other than swapping an AT for another AT (and downscoping it). It might be an AT for a structured JWT specifically targeted at one of the the particular services that the original RS needs to call. Or an AT might be exchanged for a SAML assertion to use with legacy SOAP serveries.  A good general token exchange mechanism enables lots of variations of cases like the one Justin mentioned. And more. In fact, I think downscoping might be a minority use case where what token exchange is often need for is translating tokens from what you have into what the resource you need to call can deal with.
> There need to be ways for the caller to tell the AS about the token it's asking for - by type or by the address/identifier of where it'll be used. There needs to be ways for the caller to authenticate to the AS. And there needs to be some way of expressing this delegation thing (though I'm still not totally convinced it couldn't be just the token is about the user/principal and the caller/client of the exchange is who is being delegated to).
> I realize few (approaching zero) people have or are going to read it but I have endeavored to cover all these things in the <> draft. It's an early draft so not without it some rough edges but can provide some guidance on what is needed and offers some protocol syntax for expressing it. I believe Justin's use case would be covered by it (defining a specific token type URI for an OAuth access token issued by the AS in question might be needed) as are many others.
> On Thu, Mar 26, 2015 at 1:31 PM, Justin Richer < <>> wrote:
> As requested after last night’s informal meeting, here is the token chaining use case that I want to see represented in the token swap draft.
> [ Client ]  ->   [ A ] -> [ B ] -> [ C ]
> An OAuth client gets an access token AT1, just like it always would, with scopes [A, B, C] in order to call service A, which requires all three scopes. Service A (an RS) accepts this token since it has its scope, and then needs to call service B in turn, which requires scopes [B, C]. It could just re-send the token it got in, AT1, but that would give the downstream RS the ability to call services with scope [ A ] and it should not be allowed to do that. To limit exposure, service A calls a token swap at the AS to create AT2 with scopes [ B, C ], effectively acting as an OAuth client requesting a downscoped token based on AT1. Service A then acts as an OAuth client to call service B, now acting as an RS to service A’s client, and can fulfill the request. And it’s turtles all the way down: Service B can also call service C, and now B acts as a client, requesting AT3 with scope [ C ] based on AT2, and sending AT3 to service C. This prevents C from being able to call B or A, both of which would have been available if AT1 had been passed around. Note that service A or the Client can also request a downscoped token with [ C ] to call service C directly as well, and C doesn’t have to care how it got there.
> In other words, it lets the client software be very, very dumb. It doesn’t have to do any special processing, doesn’t have to know what’s in the token, it just follows the recipe of “I got a token, I get another token based on this to call someone else”. It’s also analogous to the refresh token flow, but with access tokens going in and out. I’ve deployed this setup several times in different service deployments. Even though there is a performance hit in the additional round trips (as Phil brought up in another thread), in these cases the desire to have the tokens hold least privilege access rights (smallest set of scopes per service) outweighed any performance hit (which was shown to be rather small in practice).
> What I want is for the token swap draft to define or use a mechanism that allows us to do this. I think we can do that pretty easily by adjusting the token swap syntax and language, and explicitly calling out the semantic processing portion (the current core of the document) for what it is: a way for a token issuer to communicate to a token service specific actions. At a high level, the spec would be something like:
> 1. How to swap a token at an AS
>   1. Send a request to the token endpoint with a new grant type, and a token (of any type/format/flavor) on the way in
>   2. Get back a new token in a token response
> 2. Communicating act as / on behalf of semantics via a JWT assertion
>   1. How to create (as an AS/RS/client/other issuer) a JWT with act-as semantics
>   2. What to do (as an AS/RS) with a JWT with act-as semantics
>   3. How to create a JWT with on-behalf-of semeantics
>   4. What to do with a JWT with on-behalf-of-semantics
>   5. How to possibly represent these semantics with something other than a JWT
> Section 2 uses the syntax from section 1. Other applications, like the one I laid out above, can use the syntax from section 1 as well. This works for structured, unstructured, self-generated, cross-domain, within-domain, and other tokens.
>  — Justin
> _______________________________________________
> OAuth mailing list
> <>
> <>