[keycloak-dev] Control over audience parameter in JWT token

Marek Posolda mposolda at redhat.com
Wed Jan 6 03:49:53 EST 2016


I think you can write custom protocol mapper, which will change the 
value of audience in accessToken according to your preferences.

Some more comments/options inline...

On 06/01/16 09:29, Erik Mulder wrote:
> Bump...
> Can anybody shed his light on this? Thanks!
>
>
> On 31/12/15 12:42, Erik Mulder wrote:
>> In the JWT token there is a field 'aud', or audience, which function 
>> is to state for which client(s) that token is intended.
>> Currently (TokenManager:433) this is set to the client id:
>>
>> token.audience(client.getClientId());
>>
>> This seems fine in general, but we would like to have a token with 
>> multiple entries in the audience field. This is possible and an array 
>> value is even claimed to be the 'general case': 
>> https://tools.ietf.org/html/rfc7519#section-4.1.3 (where one single 
>> value is the 'special case')
>>
>> Background is that we have a Keycloak running for a login of a 
>> frontend that talks to multiple different resource servers. We'd 
>> prefer to use one token for all of those resource servers. The 
>> resource servers use Spring Security, which explicitly checks that 
>> the 'name' you give to your Spring service is matched by (a value of) 
>> the audience field of the JWT token. So now we have to give all 
>> resource servers the same 'name', which doesn't feel right.
Isn't is possible to disable this checking in Spring security on 
Resource server side? I think once you verify token signature and 
issuer, you should be fine.

Btv. Our adapters doesn't require that. You can have same resource 
server (REST service etc), which allows to serve requests from multiple 
different clients with different audiences in token. For example see our 
demo where "customer-portal" and "product-portal" are different clients, 
but they both access same REST service ( database.war ).

So another option for you might be to migrate to use our adapters? We 
even have Spring adapter.
>>
>> So we need some way to influence the value of the audience field. 
>> This could be achieved by following this RFC: 
>> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 which 
>> suggests to include a parameter to the request for the token. But 
>> that RFC does not consider multiple values for the audience. Another 
>> option would be to add an audience field in the settings of a Client 
>> in Keycloak. Which would, if set, define the audience field of the 
>> JWT token. This could be a comma separated string value that would 
>> translate to a JSON array. A question about this could be: 'then 
>> where to leave the client id?'. As suggested by this: 
>> https://stackoverflow.com/questions/32013835/client-id-or-multiple-audiences-in-json-web-token 
>> the best place to put the client id is in the 'azp' field (authorized 
>> party).
Maybe we can add it, but can't promise at 100%... Feel free to create 
JIRA. But IMO the audience field in client settings shouldn't be 
mandatory and if it's not set, it will default to clientId like it's 
now. This will be also backwards compatible.

Marek
>>
>> Does the KeyCloak team see this as a valuable addition? Will it be 
>> implemented somewhere in the future? Or can we make a pull request 
>> ourselves that will be merged?
>>
>> Thanks, Erik
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160106/6ce05488/attachment.html 


More information about the keycloak-dev mailing list