KNOX-3308 - Token Exchange Flow using wrong param name#1211
Merged
Conversation
Test Results21 tests 21 ✅ 1s ⏱️ Results for commit 796b06a. |
smolnar82
approved these changes
Apr 24, 2026
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.
KNOX-1234 - Token Exchange Flow using wrong param name
What changes were proposed in this pull request?
The Token Exchange flow param name is inconsistent with the core OAuth specification and requires both a full urn as the name and a hyphen rather than an underscrore: urn:ietf:params:oauth:grant-type:token-exchange
JWTFederationFilter is currently coded to expect a shortname with underscore 'token_exchange'.
In addition, UrlEncodedFormRequest wrapper has a brittle getParameter implementation that hard codes the names of params that we know indicate that the processing of the request body will be handled by us and there is not danger in consuming the response out from under another handler.
Since this is in a generic path, I want to move the knowledge of that out to the code that is handling the request processing rather than trying to keep this list in sync with the consuming code. I'll add a ServletRequestUtils to unwrap the servlet request so that we can get to the params ourselves within those specific code blocks and otherwise the wrapper will no longer treat any param names specially. This will also require the move of ServletRequestUtils to the gateway-spi module.
How was this patch tested?
Existing unit tests were corrected through the changes in the existing constants.
All unit tests were run and passed.
Integration Tests
none