Subject: [OAUTH-WG] OAuth Service Chaining

From: Justin Richer <[email-masked]>
Date: Fri, 7 Sep 2012 10:28:49 -0400

In many of the systems that I've run into, especially legacy systems, we 
have multiple independent services that need to work in concert with 
each other to fulfill a service request. In a SAML based world, somebody 
usually builds up an uber-assertion that gets passed around to all the 
services, who each check it to make sure it's got the bits in it that 
they care about. I've been asked by several people how we can solve this 
in an OAuth world, and we can of course do this same exact thing with 
OAuth bearer tokens, using either introspection or structured tokens to 
fulfill the SAML-parsing role. But I think that tokens are fundamentally 
different from assertions, and that we can do better.

What if, instead, a client gets a token from an AS, like usual, and 
passes it to the RS, like usual. But then that RS could in turn talk to 
the RS to get another token so that it can call a second RS. This 
secondary token can have at most the same rights as the original token. 
For all intents and purposes, this is the refresh tokens flow, but with 
one major difference: it's the RS that's trading one AT for another AT. 
This is important, since the RS won't ever have the refresh token (and 
shouldn't!).

With that flow in mind, I've submitted a rough outline for a new grant 
type and method of using OAuth2 bearer tokens in a chained environment, 
to facilitate discussion in this group about it. It's a pattern we plan 
on implementing here, so whether it eventually becomes a WG item or an 
individual submission, I thought it would be useful to get it out in the 
open. It doesn't yet have the normative cross-references or the formal 
IANA registration language in it, but the core of the flow is there.

   http://tools.ietf.org/html/draft-richer-oauth-chain-00

I look forward to comments and discussion.

  -- Justin

-------- Original Message --------
Subject: 	New Version Notification for draft-richer-oauth-chain-00.txt
Date: 	Fri, 7 Sep 2012 07:13:53 -0700
From: 	<[email-masked]>
To: 	<[email-masked]>

A new version of I-D, draft-richer-oauth-chain-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename:	 draft-richer-oauth-chain
Revision:	 00
Title:		 A Method of Bearer Token Redelegation and Chaining for OAuth 2
Creation date:	 2012-09-07
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-chain-00.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-chain
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-chain-00

Abstract:
    This document provides a method for a resource server to present a
    token that it has received from a client back to its authorization
    server for the purposes of receiving a derivative token for use on
    another resource server in order to chain together service requests.

The IETF Secretariat

---

From: William Mills <[email-masked]>
Date: Fri, 7 Sep 2012 07:51:32 -0700 (PDT)

Are you trying to limit how widely the more powerful token gets used so peer systems can't access each other?  What problem does this solve?  

That said I think you want to turn in an AT and get back N tokens with all possible subordinate scopes if in fact this is worth doing.  AT1 with scop "a b" could be split to "a" and "b", or it could return "a_1", "a_2", and "b" tokens.  The AS will know the mapping policy.

________________________________
 From: Justin Richer <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Friday, September 7, 2012 7:28 AM
Subject: [OAUTH-WG] OAuth Service Chaining

In many of the systems that I've run into, especially legacy systems, we have multiple independent services that need to work in concert with each other to fulfill a service request. In a SAML based world, somebody usually builds up an uber-assertion that gets passed around to all the services, who each check it to make sure it's got the bits in it that they care about. I've been asked by several people how we can solve this in an OAuth world, and we can of course do this same exact thing with OAuth bearer tokens, using either introspection or structured tokens to fulfill the SAML-parsing role. But I think that tokens are fundamentally different from assertions, and that we can do better. 

What if, instead, a client gets a token from an AS, like usual, and
    passes it to the RS, like usual. But then that RS could in turn talk
    to the RS to get another token so that it can call a second RS. This
    secondary token can have at most the same rights as the original
    token. For all intents and purposes, this is the refresh tokens
    flow, but with one major difference: it's the RS that's trading one
    AT for another AT. This is important, since the RS won't ever have
    the refresh token (and shouldn't!). 

With that flow in mind, I've submitted a rough outline for a new
    grant type and method of using OAuth2 bearer tokens in a chained
    environment, to facilitate discussion in this group about it. It's a
    pattern we plan on implementing here, so whether it eventually
    becomes a WG item or an individual submission, I thought it would be
    useful to get it out in the open. It doesn't yet have the normative
    cross-references or the formal IANA registration language in it, but
    the core of the flow is there.

 -- Justin

-------- Original Message -------- 
Subject: New Version Notification for draft-richer-oauth-chain-00.txt 
Date: Fri, 7 Sep 2012 07:13:53 -0700 
From: <[email-masked]> 
To: <[email-masked]> 

A new version of I-D, draft-richer-oauth-chain-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository. Filename:	 draft-richer-oauth-chain
Revision:	 00
Title:		 A Method of Bearer Token Redelegation and Chaining for OAuth 2
Creation date:	 2012-09-07
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-chain-00.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-chain
Htmlized: http://tools.ietf.org/html/draft-richer-oauth-chain-00 Abstract: This document provides a method for a resource server to present a token that it has received from a client back to its authorization server for the purposes of receiving a derivative token for use on another resource server in order to chain together service requests. The IETF Secretariat 

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

---

From: Justin Richer <[email-masked]>
Date: Fri, 7 Sep 2012 11:08:07 -0400

On 09/07/2012 10:51 AM, William Mills wrote:
> Are you trying to limit how widely the more powerful token gets used 
> so peer systems can't access each other?  What problem does this solve?

Exactly -- it keeps you from passing around the ubertoken to all of your 
systems, especially when they don't need it. It lets you better scope 
what each system is doing. Additionally, it gets you away from passing 
on the access token that you were passed in, which I see as an 
anti-pattern that's potentially almost as dangerous as passing along a 
user's primary credential, the original problem that OAuth sought to solve.

> That said I think you want to turn in an AT and get back N tokens with 
> all possible subordinate scopes if in fact this is worth doing.  AT1 
> with scop "a b" could be split to "a" and "b", or it could return 
> "a_1", "a_2", and "b" tokens.  The AS will know the mapping policy.

But then you'd also have to define a multi-access-token response format, 
and I think that's better left to its own pluggable mechanism. Such a 
mechanism could be used here because there's nothing in here that says 
what's returned has to be another single bearer token. (Though if you do 
that, it lets you go turtles all the way down at the next RS.)

  -- Justin

>
> ------------------------------------------------------------------------
> *From:* Justin Richer <[email-masked]>
> *To:* "[email-masked]" <[email-masked]>
> *Sent:* Friday, September 7, 2012 7:28 AM
> *Subject:* [OAUTH-WG] OAuth Service Chaining
>
> In many of the systems that I've run into, especially legacy systems, 
> we have multiple independent services that need to work in concert 
> with each other to fulfill a service request. In a SAML based world, 
> somebody usually builds up an uber-assertion that gets passed around 
> to all the services, who each check it to make sure it's got the bits 
> in it that they care about. I've been asked by several people how we 
> can solve this in an OAuth world, and we can of course do this same 
> exact thing with OAuth bearer tokens, using either introspection or 
> structured tokens to fulfill the SAML-parsing role. But I think that 
> tokens are fundamentally different from assertions, and that we can do 
> better.
>
> token. For all intents and purposes, this is the refresh tokens flow, 
> but with one major difference: it's the RS that's trading one AT for 
> another AT. This is important, since the RS won't ever have the 
> refresh token (and shouldn't!).
>
> type and method of using OAuth2 bearer tokens in a chained 
> pattern we plan on implementing here, so whether it eventually becomes 
> a WG item or an individual submission, I thought it would be useful to 
> get it out in the open. It doesn't yet have the normative 
> From: 	<[email-masked]> <mailto:[email-masked]>
> To: 	<[email-masked]> <mailto:[email-masked]>
>
>
>
> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-chain-00
>
>
> Abstract:
> [email-masked] <mailto:[email-masked]>

---

From: William Mills <[email-masked]>
Date: Fri, 7 Sep 2012 09:17:36 -0700 (PDT)

You're doubling the number of back end calls to satisfy a request though, and in the end you're only really getting a benefit when the back end system would never see an ubertoken anyway.

________________________________
 From: Justin Richer <[email-masked]>
To: William Mills <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Friday, September 7, 2012 8:08 AM
Subject: Re: [OAUTH-WG] OAuth Service Chaining

Exactly -- it keeps you from passing around the ubertoken to all of
    your systems, especially when they don't need it. It lets you better
    scope what each system is doing. Additionally, it gets you away from
    passing on the access token that you were passed in, which I see as
    an anti-pattern that's potentially almost as dangerous as passing
    along a user's primary credential, the original problem that OAuth
    sought to solve.

That said I think you want to turn in an AT and get back N tokens with all possible subordinate scopes if in fact this is worth doing.  AT1 with scop "a b" could be split to "a" and "b", or it could return "a_1", "a_2", and "b" tokens.  The AS will know the mapping policy.
But then you'd also have to define a multi-access-token response
    format, and I think that's better left to its own pluggable
    mechanism. Such a mechanism could be used here because there's
    nothing in here that says what's returned has to be another single
    bearer token. (Though if you do that, it lets you go turtles all the
    way down at the next RS.)

 -- Justin

>What if, instead, a client gets a token from an AS, like
                usual, and passes it to the RS, like usual. But then
                that RS could in turn talk to the RS to get another
                token so that it can call a second RS. This secondary
                token can have at most the same rights as the original
                token. For all intents and purposes, this is the refresh
                tokens flow, but with one major difference: it's the RS
                that's trading one AT for another AT. This is important,
                since the RS won't ever have the refresh token (and
                shouldn't!). 
>
>With that flow in mind, I've submitted a rough outline
                for a new grant type and method of using OAuth2 bearer
                tokens in a chained environment, to facilitate
                discussion in this group about it. It's a pattern we
                plan on implementing here, so whether it eventually
                becomes a WG item or an individual submission, I thought
                it would be useful to get it out in the open. It doesn't
                yet have the normative cross-references or the formal
                IANA registration language in it, but the core of the
                flow is there.

---

From: Justin Richer <[email-masked]>
Date: Fri, 7 Sep 2012 12:48:49 -0400

Part of the motivation for this is to allow for chaining to less 
tightly-bound backend systems. With an ubertoken, you've got to 
absolutely trust everybody along the chain to not do something funny 
with it. This lets us use the downscoping capabilities in OAuth to avoid 
the ubertoken issue.

But in addition, it allows for a form of light audience binding for the 
tokens if you want it. The exact mechanics of this are outside of what I 
was trying to capture in the spec, but it's basically like this:

AT1 gets issued with the following metadata (using JWT claim names fore 
convenience):

{
    "iss": "AS",
    "prn": "user->client",
    "aud": "RS1",
    "scope": "a b c d"
}

Then RS1 figures out it needs to call RS2, so it goes and gets a token 
for this using the chaining flow. Note that the chaining flow could even 
make use of client credentials in addition to the token so that *only* 
RS1 can make a redelegate call for tokens issued to it. This comes back 
with another token, AT2:

{
   "iss": "AS",
   "prn": "user->client->RS1",
   "aud": "RS2",
   "scope": "b d"
}

When RS2 gets the token, it can figure out (through structure or 
introspection or magic) that the token was issued specifically for its 
consumption by AS.

This is especially helpful if you combine the token checks with other 
context checks, such as IP and time restrictions.

And finally, you're increasing the network traffic a bit, but there are 
two mitigating factors:

1) In the back end where you're doing service processing, you can 
honestly probably handle the traffic, assuming the kind of enterprise 
setup that tends to go with this style of service chain
2) You only have to do this for each *new* token in the system when a 
request is needed. If RS1 gets handed AT1 again, it can go and use AT2 
again.

Finally-finally, you can still use ubertokens if you want to. Uber 
yourself right out! :) I've got a few concrete places where people are 
trying to get away from that and I think this gives us a solid option.

Great points all around though -- this is discussion that should be 
distilled into the introductory text, I think.

  -- Justin

On 09/07/2012 12:17 PM, William Mills wrote:
> You're doubling the number of back end calls to satisfy a request 
> though, and in the end you're only really getting a benefit when the 
> back end system would never see an ubertoken anyway.
>
> *To:* William Mills <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Friday, September 7, 2012 8:08 AM
> *Subject:* Re: [OAUTH-WG] OAuth Service Chaining
>
> passing on the access token that you were passed in, which I see as an 
>> That said I think you want to turn in an AT and get back N tokens 
>> with all possible subordinate scopes if in fact this is worth doing. 
>>  AT1 with scop "a b" could be split to "a" and "b", or it could 
>> return "a_1", "a_2", and "b" tokens.  The AS will know the mapping 
>> policy.
>
> format, and I think that's better left to its own pluggable mechanism. 
> Such a mechanism could be used here because there's nothing in here 
> that says what's returned has to be another single bearer token. 
> (Though if you do that, it lets you go turtles all the way down at the 
> next RS.)
>
>  -- Justin
>
>>
>> *From:* Justin Richer <[email-masked]> <mailto:[email-masked]>
>> *To:* "[email-masked]" <mailto:[email-masked]> <[email-masked]> 
>> <mailto:[email-masked]>
>> tokens are fundamentally different from assertions, and that we can 
>> do better.
>>