Repository navigation
Exceptions in Kubernetes federated-client-authentication signature verification are silently swallowed with no default-level log trace #51682
Description
Before reporting an issue
- I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.
Area
identity-brokering
Describe the bug
KubernetesIdentityProvider.verifySignature() catches any exception thrown while loading JWKS (network failure, malformed discovery response, NullPointerException, etc.) in a blanket catch (Exception e) { return false; }, logged only at DEBUG under org.keycloak.broker.kubernetes.KubernetesIdentityProvider. The caller, FederatedJWTClientAuthenticator.authenticateClient, then collapses the resulting failure into the generic OAuth invalid_client / "Invalid client or Invalid client credentials" response. Thus, a genuine, unexpected server-side exception produces zero log output at any level unless an operator already knows to enable DEBUG on that one specific class - nothing in the default-level server log, the admin event log, or the OAuth error response gives any indication this code path even ran, let alone why it failed.
Version
26.7.1
Regression
- The issue is a regression
Expected behavior
When verifySignature() (or the JWKS-loading path it calls into) hits an unexpected exception, its message - and stack trace? - should be logged at a level visible by default (e.g. ERROR), the same way FederatedJWTClientAuthenticator.authenticateClient's own top-level catch-all already does.
Actual behavior
The exception is caught and discarded into a bare false return value at DEBUG-only visibility. The resulting client-authentication failure is reported to both the OAuth caller and the server operator only as the generic "Invalid client or Invalid cli
8000
ent credentials" - with no way to distinguish a genuine server-side bug from a mundane credential mismatch, and no log trail pointing at the real cause unless DEBUG is manually enabled on that one class.
How to Reproduce?
- Deploy Keycloak inside a GKE cluster (cluster A) using GKE's public-issuer mode, with Keycloak's own pod using its default automounted Kubernetes ServiceAccount token at
/var/run/secrets/kubernetes.io/serviceaccount/token- i.e.automountServiceAccountTokennot disabled on Keycloak's ownServiceAccount/pod spec. - Register a
federated-jwtclient and attempt an RFC 7523 JWT-bearer client-credentials exchange from a pod in cluster A. - Observe the request fails with the generic
invalid_client/ "Invalid client or Invalid client credentials". - Check the server log at the default level (
INFO) - no line anywhere indicates this request was even processed by the Kubernetes identity-broker code, let alone why it failed. - Only after manually setting
--log-level=INFO,org.keycloak.broker.kubernetes:debugand repeating the request does the actual cause (NullPointerException: Cannot invoke "String.length()" because "this.input" is null) appear since the requests to the JWKS endpoint results in a400whose body fails to parse intoOIDCConfigurationRepresentationleaving every field (includingjwksUri) null leading to this line triggering aNullPointerException.
Anything else?
No response
Activity
keycloak-github-bot commentedon Aug 27, 2026
Due to the amount of issues reported by the community we are not able to prioritise resolving this issue at the moment.
If you are affected by this issue, upvote it by adding a 👍 to the description. We would also welcome a contribution to fix the issue.
Surface Kubernetes IdP key-loading failures and fix a resulting NPE
Surface Kubernetes IdP key-loading failures and fix a resulting NPE