[keycloak-dev] token exchange

[Stian Thorgersen]

That's not how I interpret the spec.
https://tools.ietf.org/html/rfc7519#section-4.1.3 states:

*"The "aud" (audience) claim identifies the recipients that the JWT is*
*   intended for.  Each principal intended to process the JWT MUST*
*   identify itself with a value in the audience claim.  If the principal*
*   processing the claim does not identify itself with a value in the*
*   "aud" claim when this claim is present, then the JWT MUST be*
*   rejected.  In the general case, the "aud" value is an array of case-*
*   sensitive strings, each containing a StringOrURI value.  In the*
*   special case when the JWT has one audience, the "aud" value MAY be a*
*   single case-sensitive string containing a StringOrURI value.  The*
*   interpretation of audience values is generally application specific.*
*   Use of this claim is OPTIONAL."*

>From that I read that all services that is invoked with a token should be
listed in the aud claim.

On 15 August 2017 at 17:51, Bill Burke <bburke at redhat.com> wrote:

> I don't agree with the JIRA.  See my previous email:
>
> aud" is who the token is created for.  i.e. the audience defines how the
> token is formatted: role mappings, claims, etc.
> "azp" is who the token is issued for.  In an exchange situation like above
> "aud" would be Service C, but the "azp" claim would be "B".  At least,
> that's how I have it implemented right now.
>
> On 8/15/17 9:44 AM, Stian Thorgersen 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.
>>
>
>
>