Hi Kirk,
Thanks for the feedback.
Minor suggestion: grouping the five left-most UML "actors" together would
> more clearly indicate that those actions happen on the client vs. the IdP
> and broker
Updated. Thanks!
Does the logic in KIP-1258 also support the older mechanism for specifying
> OAuth settings in sasl.jaas.config?
Yes, KIP-1258 maintains full backward compatibility with the pre-4.1 JAAS-based
configuration. The HttpRequestFormatterFactory uses the existing
ConfigOrJaas utility class (introduced in the original OAuth implementation)
which checks for configurations in this order:
1. Top-level configuration (e.g., sasl.oauthbearer.client.credentials.
client.id)
2. JAAS options (e.g., clientId in sasl.jaas.config)
This means both old and new configuration styles work seamlessly.
Thanks for adding integration tests for re-authentication to the test plan
> as this is an area that needs more coverage.
Will surely try to include this in testing. Thanks!
The existing JwtBearerJwtRetriever class has logic similar to the
> multi-tier fallback mechanism described in the KIP. Is the intention to
> retrofit existing code to use the fallback, where appropriate?
JwtBearerJwtRetriever (KIP-1139):
- Directly creates JwtBearerRequestFormatter
- No fallback mechanism
- Always uses assertions (by design - jwt-bearer grant type IS an
assertion)
I don't think JwtBearerJwtRetriever should use the fallback mechanism
because:
1. The jwt-bearer grant type is assertion-only by definition
2. Adding a client secret fallback would be semantically incorrect for this
grant type
Thanks,
Prabhash
On Wed, Jan 14, 2026 at 6:49 AM Kirk True <[email protected]> wrote:
> Hi Prabhash,
>
> Thanks for the KIP! It's very comprehensive and lays it out well.
>
> My feedback is very minor:
>
> 1. Minor suggestion: grouping the five left-most UML "actors" together
> would more clearly indicate that those actions happen on the client vs. the
> IdP and broker
> 2. Until 4.1, the "client_id" configuration was embedded as an option
> under sasl.jaas.config. In 4.1 it (along with scope and other options) were
> "promoted" to top level configuration as seen in this KIP. Does the logic
> in KIP-1258 also support the older mechanism for specifying OAuth settings
> in sasl.jaas.config?
> 3. Thanks for adding integration tests for re-authentication to the test
> plan as this is an area that needs more coverage.
> 4. The existing JwtBearerJwtRetriever class has logic similar to the
> multi-tier fallback mechanism described in the KIP. Is the intention to
> retrofit existing code to use the fallback, where appropriate?
>
> Thanks,
> Kirk
>
> On Mon, Dec 22, 2025, at 4:59 AM, Prabhash Kumar wrote:
> > Hi everyone,
> >
> > I'd like to start a discussion on* KIP-1258: Add Support for OAuth Client
> > Assertion to client_credentials Grant Type*
> >
> > *Problem:*
> >
> > Apache Kafka added support for the OAuth 2.0 client_credentials grant
> type
> > in KIP-768. The current implementation uses the traditional client
> > authentication method where a client authenticates using a client ID and
> > client secret passed via HTTP Basic authentication. While functional,
> this
> > approach has several limitations in modern cloud-native and
> > security-conscious environments.
> >
> > *Solution: *
> >
> > This KIP proposes adding support for *client assertion* as an alternative
> > authentication method for the client_credentials grant type, as defined
> in
> > RFC 7521 and RFC 7523. This enhancement addresses three key motivators:
> > Enhanced Security
> >
> > The current client secret approach requires storing long-lived secrets in
> > plain text within configuration files. This creates several security
> risks:
> >
> > -
> >
> > Secrets can be accidentally committed to version control
> > -
> >
> > Configuration files may be inadvertently exposed through backups,
> logs,
> > or monitoring systems
> > -
> >
> > Rotating secrets requires coordinating updates across all clients
> > simultaneously
> > -
> >
> > Compromised secrets provide long-term access until manually rotated
> >
> > Client assertion authentication eliminates these risks by using
> > cryptographic signatures instead of plain text secrets:
> >
> > -
> >
> > *Short-lived assertions*: Each assertion is valid only for a brief
> > period (typically 5-10 minutes), limiting the window of exposure
> > -
> >
> > *Private keys never leave the client*: Only the signed assertion is
> > transmitted, not the key material itself
> > -
> >
> > *Cryptographic proof*: The assertion provides cryptographic proof of
> the
> > client's identity without revealing the secret
> > -
> >
> > *Easier rotation*: Private keys can be rotated independently with
> > automatic file reloading
> >
> > Provider Requirements
> >
> > Some OAuth 2.0 identity providers require or strongly prefer client
> > assertion over client secrets for security and compliance reasons.
> > Organizations using these providers cannot currently use Kafka's OAuth
> > support with the client_credentials grant type. Supporting client
> assertion
> > makes Kafka compatible with any RFC 7523-compliant identity provider.
> > Industry StandardClient assertion authentication is a widely-adopted
> OAuth
> > 2.0 best practice, particularly in enterprise and regulated environments.
> > It is the recommended authentication method in many security frameworks
> and
> > compliance standards. Supporting this standard ensures Kafka follows
> > industry best practices for OAuth authentication.
> >
> > *KIP Link - *
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1258%3A+Add+Support+for+OAuth+Client+Assertion+to+client_credentials+Grant+Type
> >
> > I look forward to your feedback and suggestions.
> >
> > Regards,
> > Prabhash Kumar
> >
>
