Hi Manikumar and Kirk, Thanks for all the reviews. I intend to move the KIP to the voting phase next week.
Thanks, Prabhash On Fri, Feb 13, 2026 at 11:02 AM Kirk True <[email protected]> wrote: > Hi Prabhash, > > On Wed, Feb 11, 2026, at 12:18 AM, Prabhash Kumar wrote: > > > > > > 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? > > > > The PR introduces a new sasl.oauthbearer.assertion.claim.kid > configuration, > > but this is unnecessary because KIP-1139 already provides > sasl.oauthbearer > > .assertion.template.file which can specify the kid in the JWT header: > > ``` > > { > > "header": { > > "kid": "my-key-identifier", > > "alg": "RS256", > > "typ": "JWT" > > }, > > "payload": { > > "iss": "my-client", > > "sub": "my-service-account" > > } > > } > > ``` > > Ref: > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1139%3A+Add+support+for+OAuth+jwt-bearer+grant+type#KIP1139:AddsupportforOAuthjwtbearergranttype-FileReloading:~:text=will%20be%20ignored.-,sasl.oauthbearer.assertion.template.file,-String > > > > Kirk can maybe vouch for this. > > Yes, KIP-1139 favored the template approach to avoid having to multiple, > optional configuration for individual headers and claims. > > > > > The KIP seems focused entirely on the client side. Does the broker > > > require any changes to accept clients using assertions? > > > > Broker never sees an assertion, it always sees an access token > > > > - Broker receives SASL/OAUTHBEARER with access token (same as before) > > > > > > - Broker validates token using existing validation logic (same as > before) > > > > > > - Token format and validation are identical > > > > > > Why are the supported algorithms limited to RS256 and ES256? Is there a > > > plan to support additional algorithms? > > > > > > > - These are inherited from KIP-1139's assertion infrastructure > > - These two algorithms cover the vast majority of real-world OAuth > deploy > > ments. > > - Maybe, adding other algorithms can be taken up as future work? > > I think that was a compromise we made for KIP-1139 was to add only the > more common algorithms. Additional algorithms can be included, although > they would necessitate a KIP. > > > What happens if both `assertion.file` and `assertion.claim.iss` are set? > > > Is this considered an error, or does `assertion.file` take precedence? > > > > > It won't be an error `assertion.file` will take precedence. > > Yes, that's from KIP-1139. > > Thanks, > Kirk > > > > > 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. > > > > Noted. > > > > On Mon, Feb 9, 2026 at 2:13 PM Manikumar <[email protected]> > wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > >
