[
https://issues.apache.org/jira/browse/KAFKA-18608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18042128#comment-18042128
]
Guillaume Dufrêne commented on KAFKA-18608:
-------------------------------------------
Hi there, our development team has implemented client_credentials with
private_key_jwt (RSxxx).
Let me know if you'd like us to contribute on this topic.
We can also implement client_secret_jwt using the "HSxxx" algorithm, as we have
experience with it.
> 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
> Reporter: Szalay Levente
> Priority: Critical
> Labels: JWT, OAuth2, authentication, kafka, 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)
