[keycloak-dev] token exchange

[Pedro Igor Silva]

Sure, my question and arguments were related with Client A asking for a
token to access Service B. Service B -> Service C is what you are doing
with token exchange.

Otherwise, you will need to use token exchange in Client A to ask a token
for Service B. Where Client A is not even a resource server, thus a "aud"
claim referencing Client A is useless.

On Tue, Aug 15, 2017 at 12:58 PM, Bill Burke <bburke at redhat.com> wrote:

> 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>
> wrote:
>
>> 'aud' is broken:
>> 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> wrote:
>>
>>>
>>> On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke <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.
>>>
>>
>>
>
>