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 protected]]
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
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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>] On
Behalf Of Chuck Mortimore
Sent: Wednesday, July 15, 2015 12:47 PM
To: OAuth WG <[email protected]<mailto:[email protected]>>; Mike Jones
<[email protected]<mailto:[email protected]>>
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
Thanks for any feedback here
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
