[keycloak-dev] token exchange

[Bill Burke]

I disagree Pedro.  Needs to be based scopes and/or audience.  In our 
original example, Service B only knows he wants to talk to Service C.  
Shouldn't have to know the set of scopes he needs to "downgrade" to talk 
to C.

The original OAuth spec assumed that the browser would be involved.  
Scopes are useful in that sense as the IDP can ask for consent.  There's 
no way to ask for consent from the user in a service to service 
invocation. Hence, we have the token-exchange Draft in OAuth WG and this 
is why that spec offers both scope and audience as parameters.


On 8/15/17 9:48 AM, Pedro Igor Silva wrote:
> IMO, we should do it based on scopes. That is how OAuth2 is supposed 
> to work, specially when AS is 1:N to resource servers. Clients would 
> need to ask for a scope which can be mapped to a specific resource 
> server / client application.
>
> There are other options that we can consider, but using scopes seems 
> more aligned with the specs.
>
> On Tue, Aug 15, 2017 at 10:44 AM, Stian Thorgersen 
> <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>     'aud' is broken:
>     https://issues.jboss.org/browse/KEYCLOAK-1201
>     <https://issues.jboss.org/browse/KEYCLOAK-1201>
>
>     Big question is how do you control what the list of "clients" in
>     the aud should be? Manually? Based on scope (what about full scope
>     and loads of clients, what about when there are no client roles)?
>
>     On 15 August 2017 at 14:41, Pedro Igor Silva <psilva at redhat.com
>     <mailto:psilva at redhat.com>> wrote:
>
>
>         On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke
>         <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>
>             CLI tool I wrote doesn't allow token exchange, yet, but
>             you're correct, I'm thinking of using it to perform token
>             exchange.
>
>             Our ID tokens are not signed right now.  Also you still
>             need client to client exchange so that you can "downgrade"
>             a token to talk to an untrusted service.  I've also added
>             new fine-grain permissions "exchange-from" and "exchange-to".
>
>             For example, lets say Client A gets token and invokes on
>             service B which needs to invoke on untrusted service C.
>
>
>         When Client A gets token to invoke Service B, how the "aud"
>         claim in the token looks like for you ? Is it referencing
>         Service B ?
>
>         Asking because I noticed that our access tokens are being
>         issued using the authenticated client in "aud" claim where it
>         should contain (or in addition to other audiences) the target
>         service. A typical scenario for bearer token authentication.
>         Also, our BearerTokenRequestAuthenticator does not seem to
>         validate audience.
>
>         Considering the flow you described, Client A would need a
>         token with Service B as a valid audience in order to be able
>         to start the flow.
>
>
>