[keycloak-dev] token exchange
sthorger at redhat.com
Thu Aug 17 01:00:34 EDT 2017
That's not how I interpret the spec.
*"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:
> 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
>>> 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