Improve JWT Assertion Validation using client validators #43680

rmartinc · 2025-10-23T14:23:08Z

The PR creates a new intermediate class AbstractJWTValidator with part of the methods that previously were in AbstractJWTClientValidator. Class JWTAuthorizationGrantValidationContext in server-spi-private is now an interface (very limited now, but we can add mode methods if needed) and the real code has been moved to JWTAuthorizationJWTValidator in services which extends the AbstractJWTValidator to inherit the old methods. This way the code is shared. The signature validation is performed in the IdP side, and we can move more parts to the IdP if we want. So the current code is something in the middle. The token is validated using the client validator, but the signature is checked by the IdP. Draft for the moment. Questions:

Do you see this OK? Or do you prefer move signature to the client validator part? Or vice-versa, move token validations to the IdP side? It's a bit repeated in both sides.
The nbf claim is not checked now, I have just detected it. The client validator was not doing it before, so I will add later.
I have added the options we have currently in the IdP side (clockSkew and algorithm), but there are other options that we can add: token lifespan (default is 5m=300s) and reusePermitted (default to false). Do we want them or is it OK using fixed values for now?

I need to polish this a bit but the I want to hear your comments about the three questions before. 😄

keycloak-github-bot

Unreported flaky test detected, please review

keycloak-github-bot · 2025-10-23T15:38:16Z

Unreported flaky test detected

If the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.federation.ldap.LDAPProvidersIntegrationTest#updateLDAPUsernameTest

Keycloak CI - Base IT (5)

org.keycloak.testsuite.runonserver.RunOnServerException: java.lang.NullPointerException
	at org.keycloak.testsuite.client.KeycloakTestingClient$Server.fetchString(KeycloakTestingClient.java:185)
	at org.keycloak.testsuite.federation.ldap.LDAPProvidersIntegrationTest.updateLDAPUsernameTest(LDAPProvidersIntegrationTest.java:1656)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
...

Report flaky test

rmartinc · 2025-10-24T10:06:21Z

I have changed some class names to be more appropriate. And the nbf is already managed in the isActive of the JsonWebToken. So point 2 is already done, just the first and the third one remain.

keycloak-github-bot

Unreported flaky test detected, please review

keycloak-github-bot · 2025-10-24T11:22:18Z

Unreported flaky test detected

If the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.federation.ldap.LDAPProvidersIntegrationTest#updateLDAPUsernameTest

Keycloak CI - Base IT (5)

org.keycloak.testsuite.runonserver.RunOnServerException: java.lang.NullPointerException
	at org.keycloak.testsuite.client.KeycloakTestingClient$Server.fetchString(KeycloakTestingClient.java:185)
	at org.keycloak.testsuite.federation.ldap.LDAPProvidersIntegrationTest.updateLDAPUsernameTest(LDAPProvidersIntegrationTest.java:1656)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
...

Report flaky test

graziang · 2025-10-27T09:27:40Z

@rmartinc Thanks! That’s pretty much how I imagined it, and I’m ok with having the signature validation on the IdP side.
I was wondering if there’s a way to avoid using ClientAssertionState in JWTAuthorizationGrantValidator, since ClientAssertionState was introduced to store a state to be propagated between authenticators and is not needed for the authorization grant. Maybe it could be moved to AbstractJWTClientValidator instead of AbstractBaseJWTValidator, or handled in some other way? Not sure if that’s possible.

rmartinc · 2025-10-27T10:01:09Z

I think that the ClientAssertionState does not make any harm. It just contains the client requesting the assertion and the assertion info (jws, token, assertion and assertionType). So all the properties make sense for the JWT Authorization Grant. It's just another client autentication using an assertion. If we remove it, we need similar methods in the base class (getJWS, getToken,...). So I almost prefer to keep the state but no strong opinion here. @mposolda WDYT?

rmartinc · 2025-10-29T09:06:56Z

Rebased with the last changes added by @graziang. 😄

mposolda

@rmartinc Cool, Thanks!

I have few inline comments (Some of them are more a questions from discussion. Feedback welcome from you and @graziang as well).

Some answers to your questions:

Do you see this OK? Or do you prefer move signature to the client validator part? Or vice-versa, move token validations to the IdP side? It's a bit repeated in both sides.

I see this OK as it is now in your PR.

The nbf claim is not checked now, I have just detected it. The client validator was not doing it before, so I will add later.

In AbstractBaseJWTValidator.validateTokenActive there is a call to token.isActive , which checks also "not before" . Is it sufficient or do we need something more?

I have added the options we have currently in the IdP side (clockSkew and algorithm), but there are other options that we can add: token lifespan (default is 5m=300s) and reusePermitted (default to false). Do we want them or is it OK using fixed values for now?

IMO ok to hardcode "reusePermitted" to false for now. There is the other PR https://github.com/keycloak/keycloak/pull/43841/files , which introduces this including proper config.

For the "token lifespan", I am not sure which token you mean? Lifespan of the assertion is handled by the attributes of JWT itself. Lifespan of the issued token is the same for "jwt-bearer" grant like for any other grants AFAIK.

mposolda · 2025-10-30T11:10:42Z

services/src/main/java/org/keycloak/broker/oidc/OIDCIdentityProvider.java

+
+    @Override
+    public String getClientAssertionSigningAlg() {
+        return getConfig().getClientAssertionSigningAlg();


This effectively means that the IDP option Client assertion signature algorithm is used for both sending JWT issued by Keycloak for client authentication as well as "expected" algorithm for verification of assertions signed by the client for jwt-bearer grant.

Not 100% sure if this is good thing? Maybe it is OK for most of the cases and it is good to avoid introducing too much options. However for clients, there are different options (EG. ID Token Signature algorithm, User Info Signature algorithm), which is also prescribed in the OIDC specification.

I am like 50/50 whether to use same option or different. If we keep same option, we at least need to update the tooltip IMO.

Yes, this was not even added by @graziang, I just added because it was in the base class and makes some sense. We can remove it for the moment or change the tooltip and doc to mention that this is the algorithm to sign any client or authorization grant. Whatever you prefer is OK to me.

I'm going to remove this check for now. If we think we should validate the signing alg for the JWT authorization grant we can add a new prop or change the meaning of the current option. But we can move this forward for the moment.

Removed the check and the method in the interface JWTAuthorizationGrantProvider.

Sounds good for now. IMO we may need to do this, but likely OK as a follow-up. Thanks!

mposolda · 2025-10-30T11:23:19Z

services/src/main/java/org/keycloak/broker/oidc/OIDCIdentityProvider.java

+    public BrokeredIdentityContext validateAuthorizationGrantAssertion(JWTAuthorizationGrantValidationContext context) throws IdentityBrokerException {
+
+        // verify signature
+        if (!verify(context.getJws())) {


It seems you addressed also #43644 with this PR :-) I've assigned that issue to yourself due to that.

It may be also good to remove TODO from line 1079 as I am not sure if there is something more to validate, which we are not already validating? Besides some complex stuff, which we may do with client policies (Follow-up issue for that is #43573 ) .

Yes, I did it because using the IdP it was already done. 😄 I will remove the TODO if we accept this way of validating the signature.

rmartinc · 2025-10-30T13:49:38Z

@mposolda The lifespan is the 300 that is hardcoded here. The validateTokenActive method uses that time in case the expiration is too long or when the iat is not present to avoid very big times. It's harcoded to 300 now. In clients you can modify that default when you configure JWT to authenticate.

rmartinc · 2025-10-30T16:06:52Z

I have removed the TODO in the OIDCIdentityProvider class and removed the getClientAssertionSigningAlg in the JWTAuthorizationGrantProvider. With this the only remaining question is if we add more configuration methods in the JWT Authorization Grant:

The signing algorithm for the JWT authorization grant (same prop or new).
If reusing the same token is permitted.
The maximum expiration time that is allowed for the grant.

We can manage those as a follow-up if we agree that any of those options are needed too.

mposolda · 2025-10-31T08:33:25Z

@mposolda The lifespan is the 300 that is hardcoded here. The validateTokenActive method uses that time in case the expiration is too long or when the iat is not present to avoid very big times. It's harcoded to 300 now. In clients you can modify that default when you configure JWT to authenticate.

Ah, ok. Thanks for the clarification!

mposolda · 2025-10-31T08:42:13Z

I have removed the TODO in the OIDCIdentityProvider class and removed the getClientAssertionSigningAlg in the JWTAuthorizationGrantProvider. With this the only remaining question is if we add more configuration methods in the JWT Authorization Grant:
* The signing algorithm for the JWT authorization grant (same prop or new).

* If reusing the same token is permitted.

* The maximum expiration time that is allowed for the grant.
We can manage those as a follow-up if we agree that any of those options are needed too.

@rmartinc Thanks for the summary. I agree that those should be possible to configure. I've created a follow-up issue #43873 . The "Re-use" is already added in other subsequent PR by Giuseppe for #43568 . So IMO this PR is ready to go.

mposolda · 2025-10-31T08:44:09Z

@rmartinc Could you please rebase? I think that should help with the failing UI tests (not 100% sure, but I guess it might be related to 0f01444 )

Closes keycloak#43642 Signed-off-by: rmartinc <[email protected]>

rmartinc · 2025-10-31T08:52:24Z

Rebased!

keycloak-github-bot bot added the flaky-test label Oct 23, 2025

keycloak-github-bot bot reviewed Oct 23, 2025

View reviewed changes

rmartinc force-pushed the issue-43642 branch from 4d08f38 to 730413a Compare October 24, 2025 10:03

keycloak-github-bot bot reviewed Oct 24, 2025

View reviewed changes

mposolda requested a review from stianst October 29, 2025 08:27

mposolda self-assigned this Oct 29, 2025

rmartinc force-pushed the issue-43642 branch from 730413a to f5aee20 Compare October 29, 2025 09:06

keycloak-github-bot bot mentioned this pull request Oct 29, 2025

Flaky test: org.keycloak.testsuite.federation.ldap.LDAPProvidersIntegrationTest#updateLDAPUsernameTest #43754

Closed

mposolda mentioned this pull request Oct 30, 2025

Add signature validation of the JWT assertion for OIDCIdentityProvider #43644

Closed

graziang mentioned this pull request Oct 30, 2025

JWT Authorization grant idp config #43841

Merged

mposolda reviewed Oct 30, 2025

View reviewed changes

rmartinc force-pushed the issue-43642 branch from f5aee20 to 6a59df8 Compare October 30, 2025 16:00

mposolda mentioned this pull request Oct 31, 2025

Ability to configure max-expiration time for assertion and expected signature algorithm #43873

Closed

mposolda marked this pull request as ready for review October 31, 2025 08:42

mposolda requested a review from a team as a code owner October 31, 2025 08:42

mposolda approved these changes Oct 31, 2025

View reviewed changes

graziang approved these changes Oct 31, 2025

View reviewed changes

Improve JWT Assertion Validation using client validators

439b5e6

Closes keycloak#43642 Signed-off-by: rmartinc <[email protected]>

rmartinc force-pushed the issue-43642 branch from 6a59df8 to 439b5e6 Compare October 31, 2025 08:52

mposolda enabled auto-merge (rebase) October 31, 2025 10:26

mposolda merged commit f92adda into keycloak:main Oct 31, 2025
132 of 136 checks passed

Improve JWT Assertion Validation using client validators #43680

Improve JWT Assertion Validation using client validators #43680

Uh oh!

Conversation

rmartinc commented Oct 23, 2025

Uh oh!

keycloak-github-bot bot left a comment

Choose a reason for hiding this comment

Uh oh!

keycloak-github-bot bot commented Oct 23, 2025

Unreported flaky test detected

org.keycloak.testsuite.federation.ldap.LDAPProvidersIntegrationTest#updateLDAPUsernameTest

Uh oh!

rmartinc commented Oct 24, 2025

Uh oh!

keycloak-github-bot bot left a comment

Choose a reason for hiding this comment

Uh oh!

keycloak-github-bot bot commented Oct 24, 2025

Unreported flaky test detected

org.keycloak.testsuite.federation.ldap.LDAPProvidersIntegrationTest#updateLDAPUsernameTest

Uh oh!

graziang commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rmartinc commented Oct 27, 2025

Uh oh!

rmartinc commented Oct 29, 2025

Uh oh!

mposolda left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rmartinc commented Oct 30, 2025

Uh oh!

rmartinc commented Oct 30, 2025

Uh oh!

mposolda commented Oct 31, 2025

Uh oh!

mposolda commented Oct 31, 2025

Uh oh!

mposolda commented Oct 31, 2025

Uh oh!

rmartinc commented Oct 31, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

graziang commented Oct 27, 2025 •

edited

Loading

mposolda left a comment •

edited

Loading