An access token can have multiple audiences. You can make use of Audience Resolve protocol mapper to automatically add your web service as an audience of the access token issued to the desktop client. In Keycloak, this mapper is already defined in the default client scope roles.
How does Audience Resolve protocol mapper automatically adds client IDs as audience?
From Keycloak documentation:
An Audience Resolve protocol mapper is defined in the default client scope roles. The mapper checks for clients that have at least one client role available for the current token. The client ID of each client is then added as an audience, which is useful if your service (usually bearer-only) clients rely on client roles.
For example, for a bearer-only client and a confidential client, you can use the access token issued for the confidential client to invoke the bearer-only client REST service. The bearer-only client will be automatically added as an audience to the access token issued for the confidential client if the following are true:
- The bearer-only client has any client roles defined on itself.
- Target user has at least one of those client roles assigned.
- Confidential client has the role scope mappings for the assigned role.
If you want to ensure that the audience is not added automatically, do not configure role scope mappings directly on the confidential client. Instead, you can create a dedicated client scope that contains the role scope mappings for the client roles of your dedicated client scope.
Assuming that the client scope is added as an optional client scope to the confidential client, the client roles and the audience will be added to the token if explicitly requested by the scope= parameter.
What it means is that when the user logs into IdP with his username and password in browser, there may be a role exist that is assigned to that user and to your desktop client. If there is another client which is your web service that has been assigned that same role, then the client ID of your web service will be also added as an audience of the access token automatically.
If your desktop app always expects that your web service must be present in aud claim, you can directly add role-scope mapping to your desktop client otherwise as Keycloak recommends, create an optional dedicated client scope where you can add role-scope mapping. Then every time your desktop client requests an access token, it will have to specify that scope to include your web service as an audience.
Another option is to create an optional client scope for your desktop client and configure an Audience mapper to add client ID of your web service as an audience in that scope. When your desktop app makes authorization request, specify this optional scope. This is simpler than Audience Resolve but it becomes complex to configure if there are large number of clients in your organization as it cannot not add multiple clients automatically.
Audiencemapper to add client ID of the web service as an audience in that scope. When your desktop app makes authorization request, specify this optional scope. Then the access token will have both the client IDs inaudclaim.