Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation

From: Chuck Mortimore <[email-masked]>
Date: Wed, 15 Jul 2015 12:47:01 -0700

We're examining the use of the Token Exchange spec for API federation
use-cases, and are looking for some feedback.

The basic use-case is as follows:  Developer wants to build an Application
that is a composite of backend services that span multiple security
domains.   For example, it's a combination of Salesforce data and their own
backend services.     The application is authenticated by Salesforce, and
developer wants to exchange our ID Token for a token in the second security
domain so that login / credentials are not required for the second back-end
service.

To do this, we're planning to add configuration for multiple audiences in
our service, allowing the developer to receive a mutli-party ID Token.   We
may also add custom claims to facilitate mapping of identity across the
services.   Having logged into Salesforce, and received an ID Token, the
developer would then call a Token Exchange service in the second security
domain and exchange this ID token for a token specific to that domain.
This allows for simple API federation use-cases without converging both
APIs / backends on a common token format.

Questions / Feedback

1) In the spec, "sub" is a required field.   However, the application may
not yet know who the subject is in the second security domain ( it first
has to exchange the token )    One option might be to place the client_id
of the application as issued by the second security domain, but that seems
a bit off.   Any advice?   Should this be an Optional field?

2) Speaking of client_ids, if we don't use the "sub" to transport them, we
believe the second security domain would still appreciate this context.
The Actor field is available, but construction of a full JWT just to
transport the client_id seems like high overhead, and it may not even be
aligned with the intent of that field.    Should client_id be a claim here?

3) Speaking of Actors, It's not clear what actually states that the jwt
included in the token is actually an approved actor.    Is it intended that
the act_as or on-behalf_of tokens include an azp authorized party clam as
well?

4) "Implementations of the specification MUST implement support for using
JWTs as the Security Tokens.  Other Security Token types MAY be supported."
  This seems antithetical to the purpose of an STS.   We believe this
should be relaxed to a SHOULD

Thanks for any feedback here

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 15 Jul 2015 21:27:20 +0000

So in your scenario where you have client (c), user (u), resource (r) and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 ?

From: OAuth [mailto:[email-masked]] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <[email-masked]>; Mike Jones <[email-masked]>
Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation

We're examining the use of the Token Exchange spec for API federation use-cases, and are looking for some feedback.

The basic use-case is as follows:  Developer wants to build an Application that is a composite of backend services that span multiple security domains.   For example, it's a combination of Salesforce data and their own backend services.     The application is authenticated by Salesforce, and developer wants to exchange our ID Token for a token in the second security domain so that login / credentials are not required for the second back-end service.

To do this, we're planning to add configuration for multiple audiences in our service, allowing the developer to receive a mutli-party ID Token.   We may also add custom claims to facilitate mapping of identity across the services.   Having logged into Salesforce, and received an ID Token, the developer would then call a Token Exchange service in the second security domain and exchange this ID token for a token specific to that domain.   This allows for simple API federation use-cases without converging both APIs / backends on a common token format.

Questions / Feedback

1) In the spec, "sub" is a required field.   However, the application may not yet know who the subject is in the second security domain ( it first has to exchange the token )    One option might be to place the client_id of the application as issued by the second security domain, but that seems a bit off.   Any advice?   Should this be an Optional field?

2) Speaking of client_ids, if we don't use the "sub" to transport them, we believe the second security domain would still appreciate this context.   The Actor field is available, but construction of a full JWT just to transport the client_id seems like high overhead, and it may not even be aligned with the intent of that field.    Should client_id be a claim here?

3) Speaking of Actors, It's not clear what actually states that the jwt included in the token is actually an approved actor.    Is it intended that the act_as or on-behalf_of tokens include an azp authorized party clam as well?

4) "Implementations of the specification MUST implement support for using JWTs as the Security Tokens.  Other Security Token types MAY be supported."   This seems antithetical to the purpose of an STS.   We believe this should be relaxed to a SHOULD

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 15 Jul 2015 14:44:27 -0700

User logs into Client and accesses Resource1 using AccessToken1 from
TokenService1.

Client then contacts TokenService2 and exchanges IDToken1 from
TokenService1 for AccessToken2 from TokenService2.   It then uses
AccessToken2 to access Resource2.

-cmort

On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin <[email-masked]>
wrote:

>  So in your scenario where you have client (c), user (u), resource (r)
> and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1
> ?
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Chuck
> Mortimore
> *Sent:* Wednesday, July 15, 2015 12:47 PM
> *To:* OAuth WG <[email-masked]>; Mike Jones <[email-masked]>
> *Subject:* [OAUTH-WG] Use of Token Exchange spec for API Federation
>
>
>

---

From: Adam Lewis <[email-masked]>
Date: Wed, 15 Jul 2015 17:07:57 -0500

Hi Chuck,

Wouldn't the ACDC be a closer fit to what you are doing?  Not saying token
exchange couldn't work, but ACDC is specifically targeting your use case.

-adma

On Wed, Jul 15, 2015 at 4:44 PM, Chuck Mortimore <[email-masked]>
wrote:

>> The basic use-case is as follows:  Developer wants to build an
>> Application that is a composite of backend services that span multiple
>> security domains.   For example, it's a combination of Salesforce data and
>> their own backend services.     The application is authenticated by
>> Salesforce, and developer wants to exchange our ID Token for a token in the
>> second security domain so that login / credentials are not required for the
>> second back-end service.
>>
>>
>>
>> 2) Speaking of client_ids, if we don't use the "sub" to transport them,
>> we believe the second security domain would still appreciate this context.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 15 Jul 2015 15:38:13 -0700

Thanks Adam -  ACDC looks like it's targeted at our use-case.   Potentially
a little more difficult to layer on to our infrastructure, but looks
workable.

Does this spec live in OIDC Napps?   If so, I'll head over there to ask a
few questions

-cmort

On Wed, Jul 15, 2015 at 3:07 PM, Adam Lewis <
[email-masked]> wrote:

> On Wed, Jul 15, 2015 at 4:44 PM, Chuck Mortimore <
> [email-masked]> wrote:
>
>>> *To:* OAuth WG <[email-masked]>; Mike Jones <[email-masked]
>>> >
>>> To do this, we're planning to add configuration for multiple audiences
>>> in our service, allowing the developer to receive a mutli-party ID Token.
>>> We may also add custom claims to facilitate mapping of identity across the
>>> 1) In the spec, "sub" is a required field.   However, the application
>>> may not yet know who the subject is in the second security domain ( it
>>> first has to exchange the token )    One option might be to place the
>>> client_id of the application as issued by the second security domain, but
>>> that seems a bit off.   Any advice?   Should this be an Optional field?
>>>
>>>
>>>
>>> 4) "Implementations of the specification MUST implement support for
>>> using JWTs as the Security Tokens.  Other Security Token types MAY be
>>> supported."   This seems antithetical to the purpose of an STS.   We
>>> believe this should be relaxed to a SHOULD
>>>
>>>
>>>

---

From: John Bradley <[email-masked]>
Date: Thu, 16 Jul 2015 01:09:36 +0100

Yes it is a NAPPS thing.

The pressure for it has been reduced by the release of the Safari view controller and Chrome custom tabs.

However it still has uses for IoT and some other places.

It would be best if somehow that could align with the other token exchange proposals.

PKCE just went in to the RFC editor que, and ACDC waits to see if there is enough demand.

John B.

> On Jul 15, 2015, at 11:38 PM, Chuck Mortimore <[email-masked]> wrote:
> 
> Thanks Adam -  ACDC looks like it's targeted at our use-case.   Potentially a little more difficult to layer on to our infrastructure, but looks workable.
> 
> Does this spec live in OIDC Napps?   If so, I'll head over there to ask a few questions
> 
> -cmort
> 
> On Wed, Jul 15, 2015 at 3:07 PM, Adam Lewis <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Chuck,
> 
> Wouldn't the ACDC be a closer fit to what you are doing?  Not saying token exchange couldn't work, but ACDC is specifically targeting your use case.
> 
> -adma
> 
> On Wed, Jul 15, 2015 at 4:44 PM, Chuck Mortimore <[email-masked] <mailto:[email-masked]>> wrote:
> User logs into Client and accesses Resource1 using AccessToken1 from TokenService1.   
> 
> Client then contacts TokenService2 and exchanges IDToken1 from TokenService1 for AccessToken2 from TokenService2.   It then uses AccessToken2 to access Resource2.
> 
> -cmort
> 
> 
> 
> On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin <[email-masked] <mailto:[email-masked]>> wrote:
>   <>
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Chuck Mortimore
> To: OAuth WG <[email-masked] <mailto:[email-masked]>>; Mike Jones <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Jul 2015 00:14:43 +0000

I assume that TokenService1 is an OpenID Connect Provider, since it’s issuing both an access token and an ID Token, correct?

I assume that you want the interaction with TokenService2 to not include any user interaction – that that’s where you’re doing the Token Exchange – correct?

How did you envision the Client authenticating to TokenService2?  Is it a registered OAuth 2.0 client at TokenService2 using a Client Authentication method?  Is it signing a request to TokenService2 and TokenService2 validates and trusts the signature by Client?  Is no authentication performed other than being in possession of the ID Token serving as proof that the requester has necessary rights to do the token exchange?  Or some combination of these…?

Knowing your use case is really valuable.  Thanks for describing it for us.

                                                            -- Mike

From: Chuck Mortimore [mailto:[email-masked]]
Sent: Wednesday, July 15, 2015 2:44 PM
To: Anthony Nadalin
Cc: OAuth WG; Mike Jones
Subject: Re: [OAUTH-WG] Use of Token Exchange spec for API Federation

-cmort

On Wed, Jul 15, 2015 at 2:27 PM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
So in your scenario where you have client (c), user (u), resource (r) and resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 ?

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] Use of Token Exchange spec for API Federation

Questions / Feedback

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 15 Jul 2015 17:57:36 -0700

On Wed, Jul 15, 2015 at 5:14 PM, Mike Jones <[email-masked]>
wrote:

>  I assume that TokenService1 is an OpenID Connect Provider, since it’s
> issuing both an access token and an ID Token, correct?
>

Correct.

>
>
> I assume that you want the interaction with TokenService2 to not include
> any user interaction – that that’s where you’re doing the Token Exchange –
> correct?
>

Correct.

>
>
> How did you envision the Client authenticating to TokenService2?  Is it a
> registered OAuth 2.0 client at TokenService2 using a Client Authentication
> method?  Is it signing a request to TokenService2 and TokenService2
> validates and trusts the signature by Client?  Is no authentication
> performed other than being in possession of the ID Token serving as proof
> that the requester has necessary rights to do the token exchange?  Or some
> combination of these…?
>

We're thinking it may be a combination, but standard OAuth techniques will
likely be the easiest for the third party service to digest.    The most
basic use-cases would probably just be possession of the ID token.   I do
like the ACDC addition of the PKCE to the token material to at least bind
it to client though.

> *From:* Chuck Mortimore [mailto:[email-masked]]
> *Sent:* Wednesday, July 15, 2015 2:44 PM
> *To:* Anthony Nadalin
> *Cc:* OAuth WG; Mike Jones
> *Subject:* Re: [OAUTH-WG] Use of Token Exchange spec for API Federation
>
>
>
> So in your scenario where you have client (c), user (u), resource (r) and
> resource 1(r1) does the flow go like U->C->R-R1 or U->C->R and U->C->R1 ?
>
>
>

---

From: Adam Lewis <[email-masked]>
Date: Wed, 15 Jul 2015 20:38:43 -0500

Hi Chuck,

ACDC + PKCE is what we want to do as well.  It is a perfect fit for first
responders accessing APIs in foreign security domains.

The custom tabs / safari view controller provides an extremely elegant
means to do SSO across both native & web, utilizing session cookies in the
browser.

But ACDC is a bit more elegant from a UX vantage since it is all
back-channel.

Of course where user input it required than the custom tabs / view
controller might be better since the user can hit the authorization
endpoint and interact with the AS.  This assuming that IdP discovery is
seamless, and doesn't result in the user being confused by a NASCAR or
dropdown list or other kludgy UI on the HTML returned from the foreign AS
to the mobile's browser.

I think that ACDC will be a better fit for enterprise scenarios where the
RO is the enterprise (not the end user) vs. doing OIDC to the foreign AS
authorization endpoint.

My 2 cents.
adam

---

From: Adam Lewis <[email-masked]>
Date: Thu, 16 Jul 2015 16:33:17 -0500

btw can any of the Microsoft folks on the list give any indication if IE
has plans to do something similar to custom tabs / safari view controller
for windows devices?  Maybe it's not something you can comment on, but at
least let it be know the interest is out here :-)

On Wed, Jul 15, 2015 at 8:38 PM, Adam Lewis <
[email-masked]> wrote:

> On Wed, Jul 15, 2015 at 7:57 PM, Chuck Mortimore <
>>> How did you envision the Client authenticating to TokenService2?  Is it
>>> a registered OAuth 2.0 client at TokenService2 using a Client
>>> Authentication method?  Is it signing a request to TokenService2 and
>>> TokenService2 validates and trusts the signature by Client?  Is no
>>> authentication performed other than being in possession of the ID Token
>>> serving as proof that the requester has necessary rights to do the token
>>> exchange?  Or some combination of these…?
>>>
>>
>> We're thinking it may be a combination, but standard OAuth techniques
>> will likely be the easiest for the third party service to digest.    The
>> most basic use-cases would probably just be possession of the ID token.   I
>> do like the ACDC addition of the PKCE to the token material to at least
>> bind it to client though.
>>
>>
>>
>>>
>>>