On Wed, Jul 15, 2015 at 5:14 PM, Mike Jones <[email protected]> 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. > > > 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]> > 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]] *On Behalf Of *Chuck > Mortimore > *Sent:* Wednesday, July 15, 2015 12:47 PM > *To:* OAuth WG <[email protected]>; Mike Jones <[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
