[keycloak-dev] Audience support

[Pedro Igor Silva]

Hi Marek,

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 at redhat.com> wrote:

> 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
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>