Hi, Thanks for the KIP! I have a few comments below.
1. If I understand correctly, the original change proposed in KAFKA-18608 would be supported by Example 4 in this KIP. 2. PR https://github.com/apache/kafka/pull/21156 <https://github.com/apache/kafka/pull/21156%5D(https://github.com/apache/kafka/pull/21156)> added support for `sasl.oauthbearer.assertion.claim.kid`. Should this configuration/change also be included as part of this KIP? 3. The KIP seems focused entirely on the client side. Does the broker require any changes to accept clients using assertions? 4. Why are the supported algorithms limited to RS256 and ES256? Is there a plan to support additional algorithms? 5. What happens if both `assertion.file` and `assertion.claim.iss` are set? Is this considered an error, or does `assertion.file` take precedence? General implementation notes: 6. Please ensure there are clear logs, error messages, and tests explaining the three-tier fallback mechanism to make debugging easier. 7. Please include comprehensive documentation as part of the implementation. Thanks, Manikumar On Tue, Feb 3, 2026 at 2:27 PM Prabhash Kumar <[email protected]> wrote: > 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 > > > > > >
