[keycloak-dev] Audience support

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