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
