It can be ideal if we can support “revocation chain” for token-exchange when exchanging access-token for refresh-token .

Use-case is: The refresh token rt2 was exchanged from access token at1 . When at1 is revoked in the revocation endpoint, it will be ideal to revoke rt2 as well as all the access-tokens refreshed from rt2 . Should also remove client-session associated with rt2 .

Implementation thoughts

Hopefully it is possible to achieve it for refresh-token. Some implementation thoughts (just a though for now, maybe it is possible to achieve something like this with different/better approach):

• During client-session creation in token-exchange, we can add some note to client-session with the access-token ID of the token subject_token (The at1 token from example above).
• During access-token revocation, we can also lookup client sessions of clients in the user-session with token-exchange enabled and check the note from above. If access-token present in the note, the client-session may be invalidated. This will effectively remove refresh-tokens (as well as related access-tokens) similarly like we're doing when revocation-endpoint is triggered with the refresh-token
• The client-session note may need to contain more access-tokens (as it could be more access tokens trying to exchange for refresh-token of requester-client and revocation any of the access tokens should ideally revoke the associated refresh-token + client-session). Also it may contain expiration of access-tokens, so the expired access-tokens could be eventually removed from that note (to avoid this client session note having huge amount of entries). So probably note can contain some structure with access-tokens together with their expiration though...
• The alternative is to add the note to client-session with the client_id of the client, which the initial client was issued to. For example when access-token of client initial-client was sent as subject_token for token-exchange triggered by client requester-client, then the client session of requester-client needs to be created and it can add the client session note like te_initiated_client:initial-client , however it will need again to be a structure as client bar can have tokens exchanged from multiple different clients. So not sure if it is better to use access-token id or client-session id or something else.

Service accounts

• if we support creating refresh-tokens from the access-tokens, which were issued in the service-account grants, the approach above may be a bit more problematic as there is not sid claim in such access-tokens. However we know the service-account user, so in theory there is a way to lookup the user-session by UserSessionProvider.getUserSessionsStream(RealmModel realm, UserModel user) and check if some available session contains the client-session with the note pointing to revoked token.
  But this has performance impact though. Maybe in the case when userSession is created from token-exchange grant (the case with service-accounts as well as the case when "online" session is created from offline session - see this conversation), we rather document that revocation of access-token won't revoke the related refresh-token of exchanged clients?