Repository navigation
Make AbstractJWTClientValidator / FederatedJWTClientValidator methods protected for extensibility #49040
Description
Description
All methods on AbstractJWTClientValidator and FederatedJWTClientValidator are declared private. Downstream consumers that need to customize a single behavior (for example validateClient) cannot subclass the validator and override one method; they have to copy the full class and maintain a fork.
Changing the relevant methods from private to protected keeps the public API unchanged for normal users while letting integrators extend the validator without duplicating code.
Value Proposition
Lets integrators adapt the JWT client validator to environments Keycloak does not handle natively (e.g. managed Kubernetes, custom client lookup) without forking. Reduces drift between downstream forks and upstream over time, which in turn makes future bug fixes easier to consume.
Goals
- Change visibility of the relevant methods on
AbstractJWTClientValidatorandFederatedJWTClientValidatorfromprivatetoprotected. - Preserve current behavior and public API; this is a visibility change only.
Non-Goals
- No new extension points, SPIs, or hook methods.
- No refactor of the validator's logic or class hierarchy.
- No change to the validator's public-facing API surface.
Discussion
#48130 — see the "Code Extensibility" sub-section.
Notes
- The UDS Core-based implementation (which has already been tested on a living EKS cluster): feat(CORE-152): re-introduce the Signed JWTs to the UDS Operator defenseunicorns/uds-identity-config#838
- Small, mechanical change. A concrete list of methods to flip to
protectedcan be produced from the validators' source once this is accepted. - Useful in combination with the managed-Kubernetes work tracked in the EKS / dynamic OIDC issuer discovery issue, since that work also benefits from being able to override single validator methods.
Activity
slaskawi commentedon May 16, 2026
Dear Keycloak Maintainers, could you please assign this issue to me? Thank you!
puneetdixit200 commentedon May 16, 2026
Hello maintainers, I would like to take this issue. I will identify the validator methods that need subclassing support, change only the required private methods to protected, and add tests or compatibility checks to ensure existing behavior remains unchanged. Please assign this to me.
slaskawi commentedon May 17, 2026
Thank you for stepping up @puneetdixit200 ! Please let me know if you need any help.
ahus1 commentedon May 21, 2026
@slaskawi - please use the GitHub issue templates to create issues. Only this way your issues get the right labels. Adding them now.
Make JWT client validators extensible (#49046)
12 remaining items
Make JWT client validators extensible (keycloak#49046)