CVE-2026-79652: Keycloak-services: keycloak-services: jwt bearer authorization grant does not enforce consentrequired
A flaw was found in the JWT Bearer authorization grant implementation within the keycloak-services component of Red Hat Build of Keycloak. This component handles various OAuth2 and OpenID Connect grant types used for issuing access tokens. The issue occurs because the JWT Bearer grant fails to check if a client requires user consent before issuing a token. This allows an authenticated attacker with valid client credentials and a trusted identity provider assertion to bypass the consent requirement and obtain unauthorized access to a user account at a consent-gated client.
Other sources
A Missing Authorization flaw (CWE-862) was identified in the JWT Bearer authorization grant (urn:ietf:params:oauth:grant-type:jwt-bearer) in Keycloak. The vulnerability exists in the JWTAuthorizationGrantType.process function, which fails to verify the client.isConsentRequired flag or check for a stored UserConsentModel before issuing an access token. While other user-facing grants like Resource Owner Password Credentials (ROPC) explicitly refuse consent-required clients, and interactive grants verify stored consent, the JWT Bearer grant bypasses these checks entirely. To exploit this flaw, an attacker must have access to a confidential client credentials and a valid JWT assertion for a target user signed by an allow-listed Identity Provider (IdP). Successful exploitation allows an attacker to: Obtain a valid access token for a target user without their consent.
Access protected resources and APIs on behalf of the user.
Bypass administrative security policies intended to gate client access behind explicit user approval.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
What must an attacker possess to exploit this issue?
The attacker must be authenticated and have valid client credentials plus a trusted identity provider assertion. The affected token request uses the JWT Bearer grant type, urn:ietf:params:oauth:grant-type:jwt-bearer.
Which client configurations are exposed?
Clients configured to require user consent are exposed when tokens are issued through the JWT Bearer grant. The vulnerable processing path does not check the client consent-required setting or whether stored user consent exists.
Are other grant types described as having the same consent bypass?
The provided information identifies the JWT Bearer grant as the affected flow. ROPC explicitly refuses consent-required clients, while interactive grants verify stored consent.