Re: [OAUTH-WG] Token Chaining Use Case
The HTTP *request* should be able to be covered by a JWT signature, and that should be applicable to any interaction with the token endpoint. I’m aware that Nat’s draft is talking about the authorization endpoint, but the same logic could be applied here at the token endpoint. It could actually even be easier there because we could simply specify that the Content-Type of the input POST is application/jwt and the payload of said JWT simply contains all the parameters to the token endpoint. Orthogonal functionality that meshes well together. Brian’s draft puts everything as a parameter, including the input token (which can be arbitrary — the requester doesn’t need to know what’s in the tokens at all). This could easily be turned wholesale into an input JWT using the transform just described. The current draft is a weird halfway state where some input parameters are in a JWT that’s passed as an input parameter alongside other things that are outside the JWT. I don’t think that works particularly well, and I think there’s a better, simpler solution that solves all of these use cases and then some. — Justin On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi, On 08/07/15 01:41, Mike Jones wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:*Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case 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
Re: [OAUTH-WG] Token Chaining Use Case
Hi, On 08/07/15 01:41, Mike Jones wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:*Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case 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 michael.jo...@microsoft.com mailto:michael.jo...@microsoft.com wrote: As just updated http://self-issued.info/?p=1412, I believe that the working group token exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 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
Re: [OAUTH-WG] Token Chaining Use Case
There is a lot in common, yes. Fundamentally we're working to address the same needs, which should lead to some commonality. But I was also trying to be conciliatory in the work I did and make a good faith effort at establishing some commonality from which collaborative work could move forward. In retrospect I should probably have just outright opposed the adoption of draft-jones-oauth-token-exchange as a WG item. I thought trying to work with you would be more effective than working against you. At the time you seemed amenable to that and even proposed co-editing with. Hannes followed that indicating support for adding other co-authors (he didn't say it but kind of implied perhaps Justin and/or Phil based on prior related work). Since that time, however, there's been little willingness to consider changes to the draft (other than very trivial items). And Tony was added as a co-author, which to me (and I suspect many others) signals a complete lack of willingness to actually collaborate towards a solution that's acceptable to more than one contingent. There are differences in the drafts too. I won't list them all here but did want to call out that, contrary to what you said, the request in my draft is made up of regular old HTTP form-urlencoded POST parameters. Which is a simplification and efficiently improvement that seems to be preferred. On Tue, Jul 7, 2015 at 6:41 PM, Mike Jones michael.jo...@microsoft.com wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:* Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case 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
Re: [OAUTH-WG] Token Chaining Use Case
Hi all. After reading Brian’s note, he and I spoke on the phone to try to clear a few things up and work on a collaborative path forward. Here’s some of what we talked about… First, I’m sorry that I may have contributed to the impression that there’s little willingness on my part to consider changes to the draft. That’s not the case and the truth is actually much simpler than that… I’d been super-busy doing other things, including finishing JWT, JOSE, OAuth Assertions, helping develop and launch the OpenID Certification programhttp://openid.net/certification/, and several other valuable things, and I simply hadn’t given token exchange any significant bandwidth for a while as a result. Now that many of those things are done, I do have bandwidth to work on it now. One concrete thing Brian and I agreed to do as a next step is to work on a list of issues and choices for the working group to consider together, which we’ll jointly present in Prague. Hopefully that will help reduce some of the confusion and replace it with a clear an actionable engineering analysis of the options available to us. I know we both share the goal of keeping things as simple and efficient as possible, while enabling support for the token exchange use cases that different applications actually need. One other thing that we both think would help people better understand and use the resulting spec is to have a number of clear, illustrative examples. Face it, whatever you call it (delegation, impersonation, on-behalf-of, act-as, etc.), some of the concepts are subtle, and so the more we can shed light on them through concrete examples, the easier I suspect that we can make it for people to both understand what they are and how they apply to their use cases. I’m looking forward to seeing many of you in Prague pretty soon! -- Mike From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Wednesday, July 08, 2015 12:33 PM To: Mike Jones Cc: Justin Richer; oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case There is a lot in common, yes. Fundamentally we're working to address the same needs, which should lead to some commonality. But I was also trying to be conciliatory in the work I did and make a good faith effort at establishing some commonality from which collaborative work could move forward. In retrospect I should probably have just outright opposed the adoption of draft-jones-oauth-token-exchange as a WG item. I thought trying to work with you would be more effective than working against you. At the time you seemed amenable to that and even proposed co-editing with. Hannes followed that indicating support for adding other co-authors (he didn't say it but kind of implied perhaps Justin and/or Phil based on prior related work). Since that time, however, there's been little willingness to consider changes to the draft (other than very trivial items). And Tony was added as a co-author, which to me (and I suspect many others) signals a complete lack of willingness to actually collaborate towards a solution that's acceptable to more than one contingent. There are differences in the drafts too. I won't list them all here but did want to call out that, contrary to what you said, the request in my draft is made up of regular old HTTP form-urlencoded POST parameters. Which is a simplification and efficiently improvement that seems to be preferred. On Tue, Jul 7, 2015 at 6:41 PM, Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request *is* the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way
Re: [OAUTH-WG] Token Chaining Use Case
Agree Sergey. That line of thinking is largely why https://tools.ietf.org/html/draft-campbell-oauth-sts utilizes normal OAuth client authentication. On Wed, Jul 8, 2015 at 3:26 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: On 08/07/15 01:41, Mike Jones wrote: [...] That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token Chaining Use Case
a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:*Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case 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 michael.jo...@microsoft.com mailto:michael.jo...@microsoft.com wrote: As just updated http://self-issued.info/?p=1412, I believe that the working group token exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 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-tokenand 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 [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Thursday, March 26, 2015 3:15 PM *To:* Justin Richer *Cc:* oauth@ietf.org mailto:oauth@ietf.org *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
Re: [OAUTH-WG] Token Chaining Use Case
Probably goes without saying but I'm generally in agreement with Justin here. On Wed, Jul 8, 2015 at 5:40 AM, Justin Richer jric...@mit.edu wrote: The HTTP *request* should be able to be covered by a JWT signature, and that should be applicable to any interaction with the token endpoint. I’m aware that Nat’s draft is talking about the authorization endpoint, but the same logic could be applied here at the token endpoint. It could actually even be easier there because we could simply specify that the Content-Type of the input POST is application/jwt and the payload of said JWT simply contains all the parameters to the token endpoint. Orthogonal functionality that meshes well together. Brian’s draft puts everything as a parameter, including the input token (which can be arbitrary — the requester doesn’t need to know what’s in the tokens at all). This could easily be turned wholesale into an input JWT using the transform just described. The current draft is a weird halfway state where some input parameters are in a JWT that’s passed as an input parameter alongside other things that are outside the JWT. I don’t think that works particularly well, and I think there’s a better, simpler solution that solves all of these use cases and then some. — Justin On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi, On 08/07/15 01:41, Mike Jones wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:*Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case This approach is not a good fit for my use cases
Re: [OAUTH-WG] Token Chaining Use Case
I’m not sure how Brian’s approach solves the basic generic token exchange use case that we have From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Tuesday, July 7, 2015 4:47 PM To: Mike Jones michael.jo...@microsoft.com Cc: oauth@ietf.org oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote: As just updatedhttp://self-issued.info/?p=1412, I believe that the working group token exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 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 [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, March 26, 2015 3:15 PM To: Justin Richer Cc: oauth@ietf.orgmailto:oauth@ietf.org 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 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 jric...@mit.edumailto:jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
As just updatedhttp://self-issued.info/?p=1412, I believe that the working group token exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 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 [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, March 26, 2015 3:15 PM To: Justin Richer Cc: oauth@ietf.org 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 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 jric...@mit.edumailto:jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
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 michael.jo...@microsoft.com wrote: As just updated http://self-issued.info/?p=1412, I believe that the working group token exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 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 [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, March 26, 2015 3:15 PM To: Justin Richer Cc: oauth@ietf.org 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 http://tools.ietf.org/html/draft-campbell-oauth-sts-02 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 jric...@mit.edu mailto:jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request *is* the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike From: Justin Richer [mailto:jric...@mit.edu] Sent: Tuesday, July 07, 2015 4:47 PM To: Mike Jones Cc: Brian Campbell; oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote: As just updatedhttp://self-issued.info/?p=1412, I believe that the working group token exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 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
Re: [OAUTH-WG] Token Chaining Use Case
Because many implementations (including mine which does support my old token chaining draft) treat access tokens and refresh tokens separately in terms of data store and structure. Additionally, the refresh token is tied to the client and presented by the client. But in this case it's someone downstream, an RS, presenting the token. So unlike a refresh token being presented by the one it was issued to, this token is being presented by someone it was presented to. The feeling is close, but not quite the same in either development or assumptions. -- Justin / Sent from my phone / Original message From: Bill Mills wmills_92...@yahoo.com Date: 03/26/2015 2:24 PM (GMT-06:00) To: Justin Richer jric...@mit.edu, oauth@ietf.org oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 jric...@mit.edu 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token Chaining Use Case
See below Phil On Mar 26, 2015, at 15:15, Justin Richer jric...@mit.edu wrote: 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. 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. — Justin On Mar 26, 2015, at 2:53 PM, Phil Hunt phil.h...@oracle.com wrote: 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 phil.h...@oracle.com On Mar 26, 2015, at 1:31 PM, Justin Richer jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
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 phil.h...@oracle.com On Mar 26, 2015, at 1:31 PM, Justin Richer jric...@mit.edu 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token Chaining Use Case
+1. We all have to change production code when non final specs evolve. I particularly don't see this as a valid argument at the start of a standards discussion. Phil On Mar 26, 2015, at 15:13, Bill Mills wmills_92...@yahoo.com wrote: By definition an access token is becoming a form of refresh token.The because my implementation didn't do it that way isn't convincing me. On Thursday, March 26, 2015 12:44 PM, Justin Richer jric...@mit.edu wrote: Because many implementations (including mine which does support my old token chaining draft) treat access tokens and refresh tokens separately in terms of data store and structure. Additionally, the refresh token is tied to the client and presented by the client. But in this case it's someone downstream, an RS, presenting the token. So unlike a refresh token being presented by the one it was issued to, this token is being presented by someone it was presented to. The feeling is close, but not quite the same in either development or assumptions. -- Justin / Sent from my phone / Original message From: Bill Mills wmills_92...@yahoo.com Date: 03/26/2015 2:24 PM (GMT-06:00) To: Justin Richer jric...@mit.edu, oauth@ietf.org oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
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 jric...@mit.edu 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Token Chaining Use Case
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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token Chaining Use Case
Hey Donald, I see your point. And yes, they are no really different. However, I think this is pretty much about refreshing tokens. I understand that in this case the refresh token is not presented by its owner but someone downstream. But you are kind of refreshing a previously issued token. And maybe using a specific grant_type when refreshing can help to handle this case differently considering all its particularities. Regards. Pedro Igor - Original Message - From: Donald F. Coffin donald.cof...@reminetworks.com To: Pedro Igor Silva psi...@redhat.com, Bill Mills wmills_92...@yahoo.com Cc: Phil Hunt phil.h...@oracle.com, oauth@ietf.org Sent: Thursday, March 26, 2015 6:29:41 PM Subject: RE: [OAUTH-WG] Token Chaining Use Case Pedro, Although the registry could be changed to support the new type format, how is that any different than adding a new grant_type, such as grant_type=token_swap or grant_type=swap? Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com -Original Message- From: Pedro Igor Silva [mailto:psi...@redhat.com] Sent: Thursday, March 26, 2015 5:25 PM To: Bill Mills Cc: Donald F. Coffin; Phil Hunt; oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case Couldn't be used a specific type of refresh_token ? Instead of using grant_type=refresh_token use a grant_type=urn:ietf:params:oauth:grant_type:redelegate (or something else) as an extension to refresh token flow ? Regards. Pedro Igor - Original Message - From: Bill Mills wmills_92...@yahoo.com To: Donald F. Coffin donald.cof...@reminetworks.com, Phil Hunt phil.h...@oracle.com Cc: oauth@ietf.org Sent: Thursday, March 26, 2015 6:13:05 PM Subject: Re: [OAUTH-WG] Token Chaining Use Case The RS calling back to the AS won't be confused, the token it gets would be it's refresh token. I don't see any reason why the AS can't be smart enough to know that a token that looks like an access token it issued is usable as a refresh token for limited purposes or downscoping. On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin donald.cof...@reminetworks.com wrote: -1 Although Justin’s point might be a bit pre-mature as far as a standards discussion, the more critical reason IMHO is calling the AS’s /Token endpoint with a grant_type of “refresh_token” but providing an issued AT rather than an issued refresh_token (RT) will definitely create a backwards compatibility issue for many implementations. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case +1. We all have to change production code when non final specs evolve. I particularly don't see this as a valid argument at the start of a standards discussion. Phil On Mar 26, 2015, at 15:13, Bill Mills wmills_92...@yahoo.com wrote: By definition an access token is becoming a form of refresh token. The because my implementation didn't do it that way isn't convincing me. On Thursday, March 26, 2015 12:44 PM, Justin Richer jric...@mit.edu wrote: Because many implementations (including mine which does support my old token chaining draft) treat access tokens and refresh tokens separately in terms of data store and structure. Additionally, the refresh token is tied to the client and presented by the client. But in this case it's someone downstream, an RS, presenting the token. So unlike a refresh token being presented by the one it was issued to, this token is being presented by someone it was presented to. The feeling is close, but not quite the same in either development or assumptions. -- Justin / Sent from my phone / Original message From: Bill Mills wmills_92...@yahoo.com Date: 03/26/2015 2:24 PM (GMT-06:00) To: Justin Richer jric...@mit.edu , oauth@ietf.org oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
Again, I don't think requiring a call out to an internal token reissuer is a
general solution. That said...
The RS calls the token endpoint treating the AT as a refresh token in all cases
and using the refresh_token grant type. Desired scope is specified by the RS.
It's not in spec if there are derivative internal scopes not in the original
scope list though. This doesn't support internal scopes for partitioning that
the AS doesn't know about.
An internal AS providing chaining would need to understand the AT just as the
RS does, and treat it as a refresh token.
-bill
On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin
donald.cof...@reminetworks.com wrote:
#yiv8232628268 -- filtered {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2
4;}#yiv8232628268 filtered {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0
0;}#yiv8232628268 filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv8232628268
filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8232628268
filtered {font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv8232628268
filtered {panose-1:3 6 8 2 4 4 6 7 3 4;}#yiv8232628268
p.yiv8232628268MsoNormal, #yiv8232628268 li.yiv8232628268MsoNormal,
#yiv8232628268 div.yiv8232628268MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268 a:link,
#yiv8232628268 span.yiv8232628268MsoHyperlink
{color:blue;text-decoration:underline;}#yiv8232628268 a:visited, #yiv8232628268
span.yiv8232628268MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv8232628268
p.yiv8232628268MsoListParagraph, #yiv8232628268
li.yiv8232628268MsoListParagraph, #yiv8232628268
div.yiv8232628268MsoListParagraph
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268
p.yiv8232628268msonormal, #yiv8232628268 li.yiv8232628268msonormal,
#yiv8232628268 div.yiv8232628268msonormal
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv8232628268
p.yiv8232628268msochpdefault, #yiv8232628268 li.yiv8232628268msochpdefault,
#yiv8232628268 div.yiv8232628268msochpdefault
{margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv8232628268
span.yiv8232628268msohyperlink {}#yiv8232628268
span.yiv8232628268msohyperlinkfollowed {}#yiv8232628268
span.yiv8232628268emailstyle17 {}#yiv8232628268 p.yiv8232628268msonormal1,
#yiv8232628268 li.yiv8232628268msonormal1, #yiv8232628268
div.yiv8232628268msonormal1
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8232628268
span.yiv8232628268msohyperlink1
{color:blue;text-decoration:underline;}#yiv8232628268
span.yiv8232628268msohyperlinkfollowed1
{color:purple;text-decoration:underline;}#yiv8232628268
span.yiv8232628268emailstyle171
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none
none;}#yiv8232628268 p.yiv8232628268msochpdefault1, #yiv8232628268
li.yiv8232628268msochpdefault1, #yiv8232628268 div.yiv8232628268msochpdefault1
{margin-right:0in;margin-left:0in;font-size:10.0pt;}#yiv8232628268
span.yiv8232628268EmailStyle27
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none
none;}#yiv8232628268 .yiv8232628268MsoChpDefault
{font-size:10.0pt;}#yiv8232628268 filtered {margin:1.0in 1.0in 1.0in
1.0in;}#yiv8232628268 div.yiv8232628268WordSection1 {}#yiv8232628268 filtered
{}#yiv8232628268 filtered {font-family:Symbol;}#yiv8232628268 filtered
{}#yiv8232628268 filtered {font-family:Wingdings;}#yiv8232628268 filtered
{font-family:Symbol;}#yiv8232628268 filtered {}#yiv8232628268 filtered
{font-family:Wingdings;}#yiv8232628268 filtered
{font-family:Symbol;}#yiv8232628268 filtered {}#yiv8232628268 filtered
{font-family:Wingdings;}#yiv8232628268 ol {margin-bottom:0in;}#yiv8232628268 ul
{margin-bottom:0in;}#yiv8232628268 Bill, Can you clarify your thoughts on the
following: · What AS endpoint does the RS call and how does it present
the AT he received?
· What is the grant_type value the RS use in the above endpoint request?
· What does the AS do if the AT was issued by another AS (which is
possible using Justin’s use case)? Best regards,DonDonald F. CoffinFounder/CTO
REMI Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221 Phone:
(949) 636-8571Email: donald.cof...@reminetworks.com From: Bill Mills
[mailto:wmills_92...@yahoo.com]
Sent: Thursday, March 26, 2015 5:13 PM
To: Donald F. Coffin; 'Phil Hunt'
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case The RS calling back to the AS
won't be confused, the token it gets would be it's refresh token. I don't see
any reason why the AS can't be smart enough to know that a token that looks
like an access token it issued is usable as a refresh token for limited
purposes or downscoping. On Thursday, March 26, 2015 1:46 PM, Donald F.
Coffin donald.cof...@reminetworks.com wrote: -1 Although Justin’s point
might be a bit pre-mature as far as a standards discussion, the more critical
Re: [OAUTH-WG] Token Chaining Use Case
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 phil.h...@oracle.com wrote: 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 phil.h...@oracle.com On Mar 26, 2015, at 1:31 PM, Justin Richer jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
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 phil.h...@oracle.com wrote: See below Phil On Mar 26, 2015, at 15:15, Justin Richer jric...@mit.edu wrote: 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. 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. — Justin On Mar 26, 2015, at 2:53 PM, Phil Hunt phil.h...@oracle.com wrote: 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 phil.h...@oracle.com On Mar 26, 2015, at 1:31 PM, Justin Richer jric...@mit.edu 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,
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 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 jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
The RS calling back to the AS won't be confused, the token it gets would be
it's refresh token. I don't see any reason why the AS can't be smart enough to
know that a token that looks like an access token it issued is usable as a
refresh token for limited purposes or downscoping.
On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin
donald.cof...@reminetworks.com wrote:
#yiv0625374937 #yiv0625374937 -- _filtered #yiv0625374937
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0625374937
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0625374937
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0625374937
{font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0625374937
{panose-1:3 6 8 2 4 4 6 7 3 4;}#yiv0625374937 #yiv0625374937
p.yiv0625374937MsoNormal, #yiv0625374937 li.yiv0625374937MsoNormal,
#yiv0625374937 div.yiv0625374937MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0625374937 a:link,
#yiv0625374937 span.yiv0625374937MsoHyperlink
{color:blue;text-decoration:underline;}#yiv0625374937 a:visited, #yiv0625374937
span.yiv0625374937MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv0625374937
span.yiv0625374937EmailStyle17
{color:windowtext;font-weight:normal;font-style:normal;text-decoration:none
none;}#yiv0625374937 .yiv0625374937MsoChpDefault {font-size:10.0pt;} _filtered
#yiv0625374937 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0625374937
div.yiv0625374937WordSection1 {}#yiv0625374937 -1 Although Justin’s point
might be a bit pre-mature as far as a standards discussion, the more critical
reason IMHO is calling the AS’s /Token endpoint with a grant_type of
“refresh_token” but providing an issued AT rather than an issued refresh_token
(RT) will definitely create a backwards compatibility issue for many
implementations. Best regards,DonDonald F. CoffinFounder/CTO REMI
Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221 Phone:
(949) 636-8571Email: donald.cof...@reminetworks.com From: Phil Hunt
[mailto:phil.h...@oracle.com]
Sent: Thursday, March 26, 2015 4:22 PM
To: Bill Mills
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case +1. We all have to change
production code when non final specs evolve. I particularly don't see this as
a valid argument at the start of a standards discussion.
Phil
On Mar 26, 2015, at 15:13, Bill Mills wmills_92...@yahoo.com wrote:
By definition an access token is becoming a form of refresh token. The
because my implementation didn't do it that way isn't convincing me. On
Thursday, March 26, 2015 12:44 PM, Justin Richer jric...@mit.edu wrote:
Because many implementations (including mine which does support my old token
chaining draft) treat access tokens and refresh tokens separately in terms of
data store and structure. Additionally, the refresh token is tied to the client
and presented by the client. But in this case it's someone downstream, an RS,
presenting the token. So unlike a refresh token being presented by the one it
was issued to, this token is being presented by someone it was presented to.
The feeling is close, but not quite the same in either development or
assumptions. -- Justin / Sent from my phone /
Original message
From: Bill Mills wmills_92...@yahoo.com
Date: 03/26/2015 2:24 PM (GMT-06:00)
To: Justin Richer jric...@mit.edu, oauth@ietf.org oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 jric...@mit.edu
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
Re: [OAUTH-WG] Token Chaining Use Case
Bill, Can you clarify your thoughts on the following: * What AS endpoint does the RS call and how does it present the AT he received? * What is the grant_type value the RS use in the above endpoint request? * What does the AS do if the AT was issued by another AS (which is possible using Justin’s use case)? Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email:mailto:donald.cof...@reminetworks.com donald.cof...@reminetworks.com From: Bill Mills [mailto:wmills_92...@yahoo.com] Sent: Thursday, March 26, 2015 5:13 PM To: Donald F. Coffin; 'Phil Hunt' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case The RS calling back to the AS won't be confused, the token it gets would be it's refresh token. I don't see any reason why the AS can't be smart enough to know that a token that looks like an access token it issued is usable as a refresh token for limited purposes or downscoping. On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin donald.cof...@reminetworks.com mailto:donald.cof...@reminetworks.com wrote: -1 Although Justin’s point might be a bit pre-mature as far as a standards discussion, the more critical reason IMHO is calling the AS’s /Token endpoint with a grant_type of “refresh_token” but providing an issued AT rather than an issued refresh_token (RT) will definitely create a backwards compatibility issue for many implementations. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email:mailto:donald.cof...@reminetworks.com donald.cof...@reminetworks.com From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case +1. We all have to change production code when non final specs evolve. I particularly don't see this as a valid argument at the start of a standards discussion. Phil On Mar 26, 2015, at 15:13, Bill Mills wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com wrote: By definition an access token is becoming a form of refresh token.The because my implementation didn't do it that way isn't convincing me. On Thursday, March 26, 2015 12:44 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Because many implementations (including mine which does support my old token chaining draft) treat access tokens and refresh tokens separately in terms of data store and structure. Additionally, the refresh token is tied to the client and presented by the client. But in this case it's someone downstream, an RS, presenting the token. So unlike a refresh token being presented by the one it was issued to, this token is being presented by someone it was presented to. The feeling is close, but not quite the same in either development or assumptions. -- Justin / Sent from my phone / Original message From: Bill Mills wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com Date: 03/26/2015 2:24 PM (GMT-06:00) To: Justin Richer jric...@mit.edu mailto:jric...@mit.edu , oauth@ietf.org mailto:oauth@ietf.org oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 jric...@mit.edu mailto:jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
Pedro, Although the registry could be changed to support the new type format, how is that any different than adding a new grant_type, such as grant_type=token_swap or grant_type=swap? Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com -Original Message- From: Pedro Igor Silva [mailto:psi...@redhat.com] Sent: Thursday, March 26, 2015 5:25 PM To: Bill Mills Cc: Donald F. Coffin; Phil Hunt; oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case Couldn't be used a specific type of refresh_token ? Instead of using grant_type=refresh_token use a grant_type=urn:ietf:params:oauth:grant_type:redelegate (or something else) as an extension to refresh token flow ? Regards. Pedro Igor - Original Message - From: Bill Mills wmills_92...@yahoo.com To: Donald F. Coffin donald.cof...@reminetworks.com, Phil Hunt phil.h...@oracle.com Cc: oauth@ietf.org Sent: Thursday, March 26, 2015 6:13:05 PM Subject: Re: [OAUTH-WG] Token Chaining Use Case The RS calling back to the AS won't be confused, the token it gets would be it's refresh token. I don't see any reason why the AS can't be smart enough to know that a token that looks like an access token it issued is usable as a refresh token for limited purposes or downscoping. On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin donald.cof...@reminetworks.com wrote: -1 Although Justin’s point might be a bit pre-mature as far as a standards discussion, the more critical reason IMHO is calling the AS’s /Token endpoint with a grant_type of “refresh_token” but providing an issued AT rather than an issued refresh_token (RT) will definitely create a backwards compatibility issue for many implementations. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case +1. We all have to change production code when non final specs evolve. I particularly don't see this as a valid argument at the start of a standards discussion. Phil On Mar 26, 2015, at 15:13, Bill Mills wmills_92...@yahoo.com wrote: By definition an access token is becoming a form of refresh token. The because my implementation didn't do it that way isn't convincing me. On Thursday, March 26, 2015 12:44 PM, Justin Richer jric...@mit.edu wrote: Because many implementations (including mine which does support my old token chaining draft) treat access tokens and refresh tokens separately in terms of data store and structure. Additionally, the refresh token is tied to the client and presented by the client. But in this case it's someone downstream, an RS, presenting the token. So unlike a refresh token being presented by the one it was issued to, this token is being presented by someone it was presented to. The feeling is close, but not quite the same in either development or assumptions. -- Justin / Sent from my phone / Original message From: Bill Mills wmills_92...@yahoo.com Date: 03/26/2015 2:24 PM (GMT-06:00) To: Justin Richer jric...@mit.edu , oauth@ietf.org oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
-1 Although Justin’s point might be a bit pre-mature as far as a standards discussion, the more critical reason IMHO is calling the AS’s /Token endpoint with a grant_type of “refresh_token” but providing an issued AT rather than an issued refresh_token (RT) will definitely create a backwards compatibility issue for many implementations. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email:mailto:donald.cof...@reminetworks.com donald.cof...@reminetworks.com From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case +1. We all have to change production code when non final specs evolve. I particularly don't see this as a valid argument at the start of a standards discussion. Phil On Mar 26, 2015, at 15:13, Bill Mills wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com wrote: By definition an access token is becoming a form of refresh token.The because my implementation didn't do it that way isn't convincing me. On Thursday, March 26, 2015 12:44 PM, Justin Richer jric...@mit.edu mailto:jric...@mit.edu wrote: Because many implementations (including mine which does support my old token chaining draft) treat access tokens and refresh tokens separately in terms of data store and structure. Additionally, the refresh token is tied to the client and presented by the client. But in this case it's someone downstream, an RS, presenting the token. So unlike a refresh token being presented by the one it was issued to, this token is being presented by someone it was presented to. The feeling is close, but not quite the same in either development or assumptions. -- Justin / Sent from my phone / Original message From: Bill Mills wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com Date: 03/26/2015 2:24 PM (GMT-06:00) To: Justin Richer jric...@mit.edu mailto:jric...@mit.edu , oauth@ietf.org mailto:oauth@ietf.org oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 jric...@mit.edu mailto:jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
Couldn't be used a specific type of refresh_token ? Instead of using grant_type=refresh_token use a grant_type=urn:ietf:params:oauth:grant_type:redelegate (or something else) as an extension to refresh token flow ? Regards. Pedro Igor - Original Message - From: Bill Mills wmills_92...@yahoo.com To: Donald F. Coffin donald.cof...@reminetworks.com, Phil Hunt phil.h...@oracle.com Cc: oauth@ietf.org Sent: Thursday, March 26, 2015 6:13:05 PM Subject: Re: [OAUTH-WG] Token Chaining Use Case The RS calling back to the AS won't be confused, the token it gets would be it's refresh token. I don't see any reason why the AS can't be smart enough to know that a token that looks like an access token it issued is usable as a refresh token for limited purposes or downscoping. On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin donald.cof...@reminetworks.com wrote: -1 Although Justin’s point might be a bit pre-mature as far as a standards discussion, the more critical reason IMHO is calling the AS’s /Token endpoint with a grant_type of “refresh_token” but providing an issued AT rather than an issued refresh_token (RT) will definitely create a backwards compatibility issue for many implementations. Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Crossing Suite E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case +1. We all have to change production code when non final specs evolve. I particularly don't see this as a valid argument at the start of a standards discussion. Phil On Mar 26, 2015, at 15:13, Bill Mills wmills_92...@yahoo.com wrote: By definition an access token is becoming a form of refresh token. The because my implementation didn't do it that way isn't convincing me. On Thursday, March 26, 2015 12:44 PM, Justin Richer jric...@mit.edu wrote: Because many implementations (including mine which does support my old token chaining draft) treat access tokens and refresh tokens separately in terms of data store and structure. Additionally, the refresh token is tied to the client and presented by the client. But in this case it's someone downstream, an RS, presenting the token. So unlike a refresh token being presented by the one it was issued to, this token is being presented by someone it was presented to. The feeling is close, but not quite the same in either development or assumptions. -- Justin / Sent from my phone / Original message From: Bill Mills wmills_92...@yahoo.com Date: 03/26/2015 2:24 PM (GMT-06:00) To: Justin Richer jric...@mit.edu , oauth@ietf.org oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case 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 jric...@mit.edu 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
Re: [OAUTH-WG] Token Chaining Use Case
is treated as equal to the scope originally granted by the resource owner. The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the refresh scope MUST be identical to that of the refresh token included by the client in the request. Since the RS is attempting to obtain a new AT, what happens to the old AT that was submitted as a refresh_token, should the AS issue a new refresh_token, which it is allowed to do as stated above? Since this was really an AT, doesn’t this mean the RS and issuing AS will be required to REVOKE the AT? If the AS is not the AS that issued the original AT and there is no scope= value in the request, how does it ensure the request isn’t asking for more access than was granted by the granting AS? Best regards,DonDonald F. CoffinFounder/CTO REMI Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221 Phone: (949) 636-8571Email: donald.cof...@reminetworks.com From: Bill Mills [mailto:wmills_92...@yahoo.com] Sent: Thursday, March 26, 2015 6:04 PM To: Bill Mills; Donald F. Coffin; 'Phil Hunt' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case Again, I don't think requiring a call out to an internal token reissuer is a general solution. That said... The RS calls the token endpoint treating the AT as a refresh token in all cases and using the refresh_token grant type. Desired scope is specified by the RS. It's not in spec if there are derivative internal scopes not in the original scope list though. This doesn't support internal scopes for partitioning that the AS doesn't know about. An internal AS providing chaining would need to understand the AT just as the RS does, and treat it as a refresh token. -bill On Thursday, March 26, 2015 2:22 PM, Donald F. Coffin donald.cof...@reminetworks.com wrote: Bill, Can you clarify your thoughts on the following: · What AS endpoint does the RS call and how does it present the AT he received?· What is the grant_type value the RS use in the above endpoint request?· What does the AS do if the AT was issued by another AS (which is possible using Justin’s use case)? Best regards,DonDonald F. CoffinFounder/CTO REMI Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221 Phone: (949) 636-8571Email: donald.cof...@reminetworks.com From: Bill Mills [mailto:wmills_92...@yahoo.com] Sent: Thursday, March 26, 2015 5:13 PM To: Donald F. Coffin; 'Phil Hunt' Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case The RS calling back to the AS won't be confused, the token it gets would be it's refresh token. I don't see any reason why the AS can't be smart enough to know that a token that looks like an access token it issued is usable as a refresh token for limited purposes or downscoping. On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin donald.cof...@reminetworks.com wrote: -1 Although Justin’s point might be a bit pre-mature as far as a standards discussion, the more critical reason IMHO is calling the AS’s /Token endpoint with a grant_type of “refresh_token” but providing an issued AT rather than an issued refresh_token (RT) will definitely create a backwards compatibility issue for many implementations. Best regards,DonDonald F. CoffinFounder/CTO REMI Networks2335 Dunwoody Crossing Suite EDunwoody, GA 30338-8221 Phone: (949) 636-8571Email: donald.cof...@reminetworks.com From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case +1. We all have to change production code when non final specs evolve. I particularly don't see this as a valid argument at the start of a standards discussion. Phil On Mar 26, 2015, at 15:13, Bill Mills wmills_92...@yahoo.com wrote: By definition an access token is becoming a form of refresh token. The because my implementation didn't do it that way isn't convincing me. On Thursday, March 26, 2015 12:44 PM, Justin Richer jric...@mit.edu wrote: Because many implementations (including mine which does support my old token chaining draft) treat access tokens and refresh tokens separately in terms of data store and structure. Additionally, the refresh token is tied to the client and presented by the client. But in this case it's someone downstream, an RS, presenting the token. So unlike a refresh token being presented by the one it was issued to, this token is being presented by someone it was presented to. The feeling is close, but not quite the same in either development or assumptions. -- Justin / Sent from my phone / Original message From: Bill Mills wmills_92...@yahoo.com Date: 03/26/2015 2
