-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Support revocation for standard token exchange #37820
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
636023e to
c6b1574
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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
|
@mposolda thanks for the review. Applied your suggestions and added some description to the PR. |
mposolda
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@graziang Thanks! I hope to merge if tests are OK (I don't think UI tests failing in this PR are regression of this change, so hopefully re-run will help)
|
@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]>
|
@graziang Thanks for the rebase and update of the PR! |
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.