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 <cmortim...@salesforce.com> 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 <tony...@microsoft.com> > 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:oauth-boun...@ietf.org] *On Behalf Of *Chuck >> Mortimore >> *Sent:* Wednesday, July 15, 2015 12:47 PM >> *To:* OAuth WG <oauth@ietf.org>; Mike Jones <michael.jo...@microsoft.com> >> *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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
