Support revocation for standard token exchange#37820
Merged
mposolda merged 2 commits intokeycloak:mainfrom Mar 10, 2025
Merged
Conversation
636023e to
c6b1574
Compare
mposolda
reviewed
Mar 5, 2025
Contributor
There was a problem hiding this comment.
@graziang Thanks! I think the approach is good. Besides that, how about this scenario we discussed:
- Token
at1of clientinitial-clientwas used assubject_tokenand was exchanged for refresh tokenrt2+ access tokenat2of clientrequester1. - Then access token
at2is used assubject_tokenfor another exchange to receive refresh tokenrt3of clientrequester2. - Then after revocation
at1, it can be nice to revoke bothrt2andrt3and their client session.
I think this is not yet in your PR, is it correct? But can be probably good to do?
services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenRevocationEndpoint.java
Outdated
Show resolved
Hide resolved
services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenRevocationEndpoint.java
Outdated
Show resolved
Hide resolved
Contributor
Author
|
@mposolda thanks for the review. Applied your suggestions and added some description to the PR. |
Contributor
Author
|
@mposolda rebased and added a commit for the changed methods in |
Closes keycloak#37120 Signed-off-by: Giuseppe Graziano <[email protected]>
Closes keycloak#37120 Signed-off-by: Giuseppe Graziano <[email protected]> changed intrspection method in StandardTokenExchangeV2Test Closes keycloak#37120 Signed-off-by: Giuseppe Graziano <[email protected]>
mposolda
approved these changes
Mar 10, 2025
Contributor
|
@graziang Thanks for the rebase and update of the PR! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #37120
This PR addresses the following scenario:
If you start with
at1, rt1with thesubject_clientand refresh the tokens several times, you can obtainat2, rt2andat3, rt3. If allowed, you can use one of these tokens assubject-tokento perform token exchange, requesting a refresh token and obtainingat4, rt4forrequester-clientwith a new client session forrequester-client.Now, suppose you perform another token exchange using
requester-client2, usingat4assubject_token, and obtainat5, rt5.With this PR, if any of
at1, rt1, at2, rt2, at3, rt3is revoked via the revocation endpoint,at4andrt4are also revoked, and the corresponding client session forrequester-clientis deleted.at5andrt5are also revoked, along with the client session forrequester-client2.To implement this revocation chain, a client session note is used to track the client-id of the
subject_token.A detail has been added to the
REVOKE_GRANTevent to track the revoked client ids due to token exchange. A test has been added for the described cases.