Cool, should have audience PR ready in next few days then. Will create
"future" version JIRA for the "Resource" specs.
On 10/09/18 09:21, Stian Thorgersen wrote:
As aud field is widely used today that is what we need now. I
seen anyone ask for  so I think we can safely ignore that spec for
I would finish what you have with aud support for now, then we can
address  in the future if needed.
On Thu, 6 Sep 2018 at 23:37, Marek Posolda <mposolda(a)redhat.com
I have some concerns about the audience support. The prototype
months ago, which I have in my branch  is based on client
showed it on the weekly demo some time ago and changed few things
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
- Adds the easy way to generate "audience client scope" for specified
"service" client (usually bearer-only client). This clientScope
-- the audienceProtocolMapper of bearer-only described above
-- the scope role mappings of all the client roles of that
The "frontend" clients can then use this clientScope, so that
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
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
by something else.
- It introduces "resource" parameter, which MUST be an absolute
this specification and it should point to the service/resource
access token will be used. When authorization server is creating
it may apply audiences, encrypt token by various algorithms based
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
identifier for the resource server."
- The "resource" parameter is used in the token request if
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
code-to-token or refresh-token requests. This is great and allows
cool flexibility (unlike "scope" where the whole SSO login
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
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
"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
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
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
various possibilities, and it still looks good to represent
support through client scopes. So optional clientScopes can be
either through "scope" parameter (default case) or through
parameter (probably disabled by default) or through both.
keycloak-dev mailing list