[keycloak-dev] token exchange
Pedro Igor Silva
psilva at redhat.com
Tue Aug 15 09:48:53 EDT 2017
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.
>>
>
>
More information about the keycloak-dev
mailing list