I think "resource" will be a good addition but we are already capable of
choosing/processing audiences using scopes. So yeah, IMO, we can go for #1.
On Thu, Sep 6, 2018 at 5:28 PM, Marek Posolda <mposolda(a)redhat.com> wrote:
I have some concerns about the audience support. The prototype done few
months ago, which I have in my branch  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
The "frontend" clients can then use this clientScope, so that audience +
roleMappings will be both available in the accessToken issued for the
Now there is this specs , which Pedro pointed. Short summary about
- 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
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
parameter (probably disabled by default) or through both.
keycloak-dev mailing list