Subject: [OAUTH-WG] Token Chaining Use Case

From: Justin Richer <[email-masked]>
Date: Thu, 26 Mar 2015 13:31:17 -0500

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

---

From: Bill Mills <[email-masked]>
Date: Thu, 26 Mar 2015 19:24:07 +0000 (UTC)

So why can't the access tokne simply be re-used as a refresh token?  Why would it need a new grant type at all?

     On Thursday, March 26, 2015 11:31 AM, Justin Richer <[email-masked]> wrote:

 — Justin
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Thu, 26 Mar 2015 14:53:36 -0500

What if A calls be with it’s own authorization token (server token ST1) and passes AT1 in another header e.g. on-behalf-of.

You save a call and can still check the scope downstream. Further, service B and C can each check whether ST1 and ST2 had the right to wield AT1 even when AT1’s POP proof is a proof of the external client.

The only reason I can think to call the AS is if there is some dynamic condition that might cause an AS to reject the swap.  If AT1 is valid, I can’t think of another reason why the answer isn’t already YES for all calls. If its no, its likely a permanent configuration problem not a dynamic decision.  In other words, B always expects A to call it on behalf of some one.  Likewise, C is always expecting B.

Phil

@independentid
www.independentid.com
[email-masked]

> On Mar 26, 2015, at 1:31 PM, Justin Richer <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Mar 2015 15:15:33 -0500

Your service layout will determine whether or not each bit calls the same AS that issued the original token, since you can easily do it across boundaries if your AS takes in cross domain tokens. That’s another benefit of having it be a generic token swap, you can build it out using the same mechanism and get both behaviors.

The AS could reject the swap for any number of conditions: wrong client asked, token is expired, scopes don’t align, bad token, etc.

You can always optimize your system such that you just send a high-powered token down the chain, in which case you’re not using token swapping. This is not for those cases, obviously. This is for the cases when you *are* doing token swapping and usually downscoping the privileges.

 — Justin

> On Mar 26, 2015, at 2:53 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 26 Mar 2015 15:24:57 -0500

See below

Phil

> On Mar 26, 2015, at 15:15, Justin Richer <[email-masked]> wrote:
> 

There is no high power token in my new proposal. Each server must act on its own authority with its own token. The original at is passed as evidence of scoped authority to the internal services. 

There is no super token.

---

From: Bill Mills <[email-masked]>
Date: Thu, 26 Mar 2015 20:35:54 +0000 (UTC)

Requiring a round trip to the AS is going to have a huge headwind for implementation in high performance environments.
I think we need to pursue something like what Phil is talking about where the intermediary server has it's own credential or authority.  

     On Thursday, March 26, 2015 1:25 PM, Phil Hunt <[email-masked]> wrote:

 See below

Phil

There is no super token.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 26 Mar 2015 17:15:23 -0500

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
http://tools.ietf.org/html/draft-campbell-oauth-sts-02 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 <[email-masked]> 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.
>
>
> 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. Send a request to the token endpoint with a new grant type, and a
> token (of any type/format/flavor) on the way in
> 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
>