[jira] [Commented] (KAFKA-18608) Enhancing Apache Kafka OAuth2 Authentication: Adding Support for private_key_jwt Client Assertion

["Prabhash Kumar (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-18608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18068027#comment-18068027 ] 

Prabhash Kumar commented on KAFKA-18608:
----------------------------------------

The main PR [https://github.com/apache/kafka/pull/21483] was merged last week.

Created a DOCS PR [https://github.com/apache/kafka/pull/21859]

cc: [~kirktrue] [~omkreddy] 

> Enhancing Apache Kafka OAuth2 Authentication: Adding Support for private_key_jwt Client Assertion
> -------------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-18608
>                 URL: https://issues.apache.org/jira/browse/KAFKA-18608
>             Project: Kafka
>          Issue Type: New Feature
>          Components: clients, security
>            Reporter: Szalay Levente
>            Assignee: Prabhash Kumar
>            Priority: Critical
>              Labels: JWT, OAuth2, authentication, kafka, kip-1258, oauth2
>
> I would like to propose a new feature for Apache Kafka to include support for *private_key_jwt client assertion* as an additional OAuth2 authentication mechanism, alongside the currently available *JWKS client_credentials* method.
> h3. *Why Add Support for private_key_jwt?*
> The OAuth2 specification allows various authentication flows, and while *client_credentials* is widely used, the *private_key_jwt* method offers significant advantages in terms of {*}security{*}, {*}flexibility{*}, and *compatibility* with modern standards. Here's why private_key_jwt would be a valuable addition:
>  # {*}Enhanced Security{*}:
>  * 
>  ** In the *client_credentials* flow, client secrets are often stored and transmitted directly, which introduces a risk if these secrets are exposed.
>  ** With {*}private_key_jwt{*}, no static secret is stored or shared. Instead, a *signed JWT (JSON Web Token)* is used for authentication, and the private key remains securely stored on the client side.
>  ** This approach minimizes the attack surface and aligns with best practices for secure authentication, particularly in cloud and distributed environments.
>  # {*}Standards Compliance{*}:
>  * 
>  ** *private_key_jwt* is defined in the OAuth 2.0 specification (RFC 7523), making it a standard and interoperable choice for modern systems.
>  ** It's increasingly adopted in enterprise-grade identity providers like {*}Keycloak{*}, {*}PingID{*}, {*}Azure AD{*}, and others, ensuring compatibility with a wide range of authentication servers.
>  # {*}Use Case Flexibility{*}:
>  * 
>  ** The ability to authenticate using private_key_jwt is particularly useful in scenarios where:
>  *** Rotating keys is required for enhanced security.
>  *** Secrets must not be stored in plain text (e.g., containerized or serverless applications).
>  *** Authentication needs to scale across multiple services or microservices without duplicating secrets.
>  # {*}Future-Proofing Kafka{*}:
>  * 
>  ** As organizations move toward implementing *Zero Trust architectures* and increasingly rely on {*}JWT-based token systems{*}, supporting *private_key_jwt* ensures Kafka remains competitive and aligned with modern authentication paradigms.
>  ** It demonstrates Kafka's commitment to meeting enterprise security requirements, making it more attractive for organizations that prioritize security.
>  # {*}Interoperability with Keycloak{*}:
>  * 
>  ** Many Kafka users already rely on *Keycloak* as their Identity Provider (IdP). *Keycloak* natively supports private_key_jwt, and enabling Kafka to authenticate with this method would simplify integrations and reduce the need for custom workarounds.
>  ** Keycloak's documentation on private_key_jwt can be found here.
> h3. {*}Proposed Implementation{*}:
>  * Introduce a configuration option to enable *private_key_jwt* for OAuth2 authentication in Kafka.
>  * Allow users to specify:
>  * 
>  ** The *private key file or key store* for signing JWTs.
>  ** The *algorithm* used (e.g., RS256, ES256).
>  ** The *token endpoint* for requesting access tokens.
>  ** Optional: Key rotation settings or additional JWT claims.
>  * Ensure the implementation adheres to RFC 7523 and remains backward compatible with the existing client_credentials method.
> h3. {*}Benefits of Implementing This Feature{*}:
>  * Increased adoption of Kafka in {*}high-security environments{*}.
>  * Easier integration with {*}modern IdPs{*}.
>  * Enhanced flexibility for developers and operations teams managing Kafka deployments.
>  * Future-proofing Kafka's authentication options by aligning with evolving standards.
> For more details on private_key_jwt and its benefits, see:
>  * [RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication|https://www.rfc-editor.org/rfc/rfc7523.html]
>  * [PingID Documentation - Client Authentication with JWT|https://docs.pingidentity.com/pingfederate/latest/administrators_reference_guide/pf_jwks_endpoint.html]
>  * [OAuth 2.0 Best Current Practice|https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics]
> By implementing this feature, Apache Kafka will provide a more secure and modern authentication option, aligning with the needs of today's enterprise environments and ensuring compatibility with advanced OAuth2-based systems.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)