Repository navigation
Conversation
Signed-off-by: Inf1mum <Inf1mum@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Shared SSO cookies are not cleared between tests, so subsequent tests skip the login form and fail before exercising their audience assertions.
1 open issue
What changed in this PR
This PR addresses #54743 by requiring a string-valued issuer audience in client assertions when the secure assertion executor applies, while leaving general JWT client authentication unchanged.
Changes:
- Validate the raw JSON audience type and issuer value instead of the normalized token audience.
- Add integration tests for string and array audiences, including acceptance without the policy.
| File | Description |
|---|---|
tests/base/src/test/java/org/keycloak/tests/client/policies/SecureClientAuthenticationAssertionExecutorTest.java |
Adds audience validation and non-policy compatibility tests. |
services/src/main/java/org/keycloak/services/clientpolicy/executor/SecureClientAuthenticationAssertionExecutor.java |
Requires aud to be a JSON string equal to the realm issuer. |
Review effort: Balanced
| } | ||
|
|
||
| private AccessTokenResponse requestTokenWithAudience(JsonNode aud) { | ||
| oauth.doLogin("test-user@localhost", "password"); |
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
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 #54743
What
With the FAPI 2.0 / OAuth 2.1 client profiles (
secure-client-authentication-assertionexecutor), a client authentication assertion whoseaudclaim is a single-element JSON array containing the issuer (for example["https://host/realms/myrealm"]) was accepted. FAPI 2.0 Security Profile (Final), §5.3.2.1 requires the authorization server to accept only its issuer identifier, as a string, in theaudclaim of client authentication assertions.How
SecureClientAuthenticationAssertionExecutorpreviously decoded the assertion intoJsonWebTokenand validated the audience throughgetAudience(). Because theaudfield is annotated with@StringOrArray, a JSON string and a single-element array are indistinguishable after deserialization, which let["<issuer>"]pass both thelength != 1and thehasAnyAudiencechecks.The executor now reads the assertion payload as a JSON tree and requires the
audclaim to be a textual node equal to the realm issuer. All the other cases keep their existing behavior: missing audience, multiple audiences and non-issuer audiences are still rejected withinvalid audience in client assertion.The change is scoped to the executor, which is only active in the
fapi-2-dpop-security-profile,fapi-2-dpop-message-signingandoauth-2-1-*default profiles. The general (non-FAPI)private_key_jwt/client_secret_jwtclient authentication flow is untouched and continues to accept the array form, so the semantics of theallow-multiple-audiences-for-jwt-client-authenticationrealm option are unaffected.Testing
Added
SecureClientAuthenticationAssertionExecutorTestcovering:aud= issuer as a string is accepted with the profileaud=["<issuer>"](single-element array) is rejected with the profile (the case from the issue)aud=["<issuer>", "<other>"]is rejected with the profileaud= token endpoint URL as a string is still rejected with the profileaud=["<issuer>"]is still accepted without the profile (general flow unchanged)The integration tests run in CI.