Keycloak - large tokens - lazy role evaluation

I am currently using Keycloak (v11) as an identity broker for authentication and authorization. One issue I am facing is that the JWT tokens generated by Keycloak tend to get very large if a user has many roles. Currently, the project that uses Keycloak for identity brokering consists of multiple micro services (clients, in Keycloak terms). This leads me to ask two questions:

  1. Why is it that a specific client / resource asks for a JWT, the JWT comes with all client roles for that user (including client roles for other clients)? Would it break any pattern in Open ID Connect if I changed the default client scope, so that only the specific client roles related to a client would appear? Or would that specific pattern have a different name?
  2. Is there a OIDC related pattern, where one first authenticates and then “lazy evaluates” authorization related questions like roles? That is, I would like some agent Bob to authenticate via Keycloak, and whenever Bob wants to use some service protected by a role, Bob asks Keycloak whether he has that specific role. The purpose of this would be to minimize the token size.

(not an expert here)
By default all clients have “Full scope allowed”
If you unselect this, you can choose what client roles you would like in your JWT.
It also impacts audience (aud).

However initially if you log in a user for example, you may want them to have a token usable for all services…

The way I’m doing it, I get a first token from “my-login-service”, with no roles at all, or maybe “account” roles and realm roles.
Then if I need to call a service, I exchange the token for a different client token. In this client’s mapper, I set the scope to only the current client, all roles.
I also hard-code the audience to the service id (by default azp doesn’t go into the audience field, but OAuth recommends providing an id… not the client id, but the target service id).

So the resulting token will have only roles for that particular client.
actually, this means that the “aud” claim is redundant, because the service may simply check for any roles, but that’s a different question

For all this I need token exchange, which is available only in preview feature, so it needs to be activated at server launch by using the appropriate option.