Repository navigation
Audience mapping for dynamic clients (DCR) #51229
Replies: 1 comment
|
I went looking for a built-in mechanism before answering, since I wasn't sure either. I listed every executor under So: there's no built-in executor or registration policy that auto-adds an audience mapper for you. Your instinct is right — post-processing newly registered clients yourself is the intended extension point for this, since neither of the two subsystems Keycloak ships for DCR has an "auto-configure this" hook, only "allow/deny this" hooks. A custom I can't speak for whether the team would want a contribution here (that's really a maintainer call, not something I can answer from the code), but given how much of the existing executor list is single-purpose knobs like this, an "AudienceMapperExecutor" wouldn't look out of place alongside them if you want to make the case in an issue. |
Uh oh!
There was an error while loading. Please reload this page.
We use Dynamic Client Registration (DCR) to create a large number of clients. Some of these clients, or the resource servers associated with them, need to call the token introspection endpoint. Since the audience validation introduced in PR #49131, the client authenticating to the introspection endpoint must be present in the token's
audclaim. For DCR-created clients, the audience is empty by default.There is an OIDC compatibility option available to disable audience verification, but we have not found a way to enable it through DCR and assume this is intended only as a temporary compatibility mechanism.
My current understanding is that audience mappings need to be configured for DCR-created clients so that the appropriate audience is included in issued tokens. It seems possible to automate such configuration using executors triggered by DCR registration events. However, my main question here is whether this is the approach Keycloak intends users to take, or whether there is another recommended pattern.
Specifically:
All reactions