midnight
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(a)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(a)redhat.com> wrote:
>
> On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke <bburke(a)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.
>