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 >
