[keycloak-dev] Audience support

[Marek Posolda]

Hi,

I have some concerns about the audience support. The prototype done few 
months ago, which I have in my branch [1] is based on client scopes. I 
showed it on the weekly demo some time ago and changed few things based 
on the feedback. Just to clarify, the PR:
- Adds the AudienceProtocolMapper, which is able to attach single 
client_id of the specified client (typically will be bearer-only client)

- Adds the easy way to generate "audience client scope" for specified 
"service" client (usually bearer-only client). This clientScope contains:
-- the audienceProtocolMapper of bearer-only described above
-- the scope role mappings of all the client roles of that bearer-only 
client.
The "frontend" clients can then use this clientScope, so that audience + 
roleMappings will be both available in the accessToken issued for the 
frontend-client.

Now there is this specs [2], which Pedro pointed. Short summary about 
this specs:

- It is still in draft state for few years and there are some TODO in 
it. So hard to say how much to rely on it...

- It specifically talks about "scope" parameter and mentions, that it is 
often used by various parties for "what the token can be used for" 
(permissions/claims associated with the token) and "where to use that 
token" . But it mentions that "where" use-case should be ideally handled 
by something else.

- It introduces "resource" parameter, which MUST be an absolute URI per 
this specification and it should point to the service/resource where the 
access token will be used. When authorization server is creating token, 
it may apply audiences, encrypt token by various algorithms based on the 
requested "resource" etc. For the audience, they specify that:

"The authorization server may use the exact 'resource' value as the 
audience or it may map from that value to a more general URI or abstract 
identifier for the resource server."

- The "resource" parameter is used in the token request if possible. For 
the grants where it's not possible (implicit, resource owner password 
login, client credentials) it is used in the initial authentication 
request. So for the classic "authorization_code" grant it can be used in 
code-to-token or refresh-token requests. This is great and allows some 
cool flexibility (unlike "scope" where the whole SSO login including all 
the redirects is needed). But it requires some support on adapters.


Now I am thinking about 2 possible ways to continue:

1) Finish my current work around audience and for now, let it be driven 
through the "scope" parameter. Then later add the support for the 
"resource" parameter and the specs above.
2) Skip what I currently have and start something different based on the 
"resource" parameter specs.

ATM I am more keen to option 1, so that we can have some audience 
support in master ASAP. Also because the specs is still draft and I 
don't know how much we can rely on the "resource" parameter being 
adopted by 3rd party applications (for example Openshift). When we later 
have the option to drive audiences through both "scope" and "resource" 
params, it will be good thing IMO.

The "resource" related support will require changes on the adapter side 
as it is new parameter to be supported in code-to-token request and 
refresh-token request. On our adapter's side, it will be good to have 
some changes to allow "cache" of more access tokens for various 
resources/audiences, not just one. On server-side, I was thinking about 
various possibilities, and it still looks good to represent "resource" 
support through client scopes. So optional clientScopes can be requested 
either through "scope" parameter (default case) or through "resource" 
parameter (probably disabled by default) or through both.

Thoughts?


[1] https://github.com/mposolda/keycloak/tree/audience
[2] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-00

Marek