The new standard token exchange feature in Keycloak does not currently support delegation semantics from the token exchange specification, which also means it's missing the ability to (in the words of Keycloak not the spec) allow and admin to impersonate a different user.

We should extend on the new standard token exchange feature to introduce delegation support.

In a delegation token exchange we would require both the subject_token and the actor_token. We would also need to document some examples of how an application could go about getting both these tokens, some examples include:

• Login to an admin console as admin@domain (actor_token); and initiate a CIBA flow to request user@domain to authorize impersonation (subject_token)
• What else? We need to think some more about this

In terms of act claim we can make this configurable and have some options like:

• may_act must match the subject of the actor_token; which is then added to the issued token act claim. This could be configurable and allow an empty may_act in the subject_token for example
• act can be optionally filled with details of the client doing the token request when there is no actor_token

There may be quite a lot of use-cases as well where it would be difficult to obtain a subject_token; we can consider that there is two modes; one that requires user consent to being impersonated, and another where an admin can impersonate select users without user consent. In the latter we could allow subject_token to simply be a JWT that the client could generate, or perhaps require the client to create JWS with its own keypair. We could also combine this with Authorization Grants (RFC7521) where if there is a trusted identity provider that can be used to create assertions that can be used to obtain a subject_token.