This issue is about support for the delegation as mentioned in the token exchange specification. The most relevant specification sections:

• https://datatracker.ietf.org/doc/html/rfc8693#name-delegation-vs-impersonation
• https://datatracker.ietf.org/doc/html/rfc8693#name-act-actor-claim
• https://datatracker.ietf.org/doc/html/rfc8693#name-may_act-authorized-actor-cl
• https://datatracker.ietf.org/doc/html/rfc8693#name-delegation-token-exchange-e (Example. It is in the end of the specs, but maybe best to start with to grasp what the delegation is about)

Notes and considerations

Some random notes here for now. Comments welcome on this issue about the possible use-cases and if the notes from here makes sense to cover your particular use-case.

• Delegation is IMO better and safer than "subject impersonation" (subject impersonation is the case when the token sub is required to be changed) due to this:

  • The delegation does not change the sub claim. So the exchanged token still has same user in the sub claim as the original subject_token had.
  • The great thing is, that exchanged token from the delegation contains both sub and act claims. Hence the exchanged token has all the informations like This token has subject of user "normal-user", but the actor using this token is "admin-user" . It gives some additional info to resource-server applications as they can differentiate between the case when the token is:
    • Normal token issued to the sub user where the actor is really the sub user (Normal use-case)
    • Delegated token with both sub and act claims where the application knows that actor is really the admin user.

• Do we need to support delegation just with requested_token_type=urn:ietf:params:oauth:token-type:access_token ? Or do we need to support also refresh tokens? Access tokens are easier and more safe IMO and can be nice if we can start just with supporting those (unless there are requirements for refresh tokens)

• Do we want to allow the delegation just if the may_act claim is present in the subject_token as shown in the example in the token exchange specification (link above)? It will be nice if we can start with requiring may_act claim IMO

• Question is, how is the may_act claim created in the subject token in the first place? Note that this is even before the token-exchange request itself (as it is relevant to issuing the subject_token during initial authentication). I can see some potential for "dynamic client scopes" (which are experimental feature at the time of this writing).

• I guess that in many cases, it could be great to show the consent screen to the user like Grant admin user to act on your behalf during initial authentication. It can be perhaps useful if this consent screen is shown even if client has Consent Required OFF

Example delegation scenario

1. Initial authentication is done by user user . The initial OIDC request will contain something like scope=may_act:admin (would require dynamic client scopes)

• The consent screen is shown to the user Grant user 'admin' to act on your behalf (optional)

• The client scope may_act would contain some protocol mapper, which will add the may_act claim to the subject-token for user admin

2. User admin authenticates in the meantime to receive his own token (later being used as actor_token)

3. The token-exchange request is sent with subject_token=subject-token-from-step-1&actor_token=admin-token-from-step-2

4. Token exchange request would need to verify both subject_token and actor_token . Besides normal verifications of actor_token (session exists, user exists and is enabled etc), it should be verified that actor_token subject MUST be the same as subject_token subject from may_act claim. Verified tokens added as notes to KeycloakSession (ideal is if we don't need to persist subject_token and actor_token into clientSession)

5. Some protocol mapper, which will add act claim to the exchanged token as long as verified subject_token and actor_token are present in the KeycloakSession. In case of exchanging to refresh-tokens, some claim should be added to the isseued refreshToken, so that further refreshes of that refresh-token can add act claim as well.