Hi Lianet, Thanks for your feedback. LM0: Regarding the fall-back mechanism (from client assertions to the > weaker client-secret), the KIP describes using it based on configs > (fallback if no assertion configs found), makes sense. But what if the > assertions are configured but fail? I expect there won't be any fallback in > that case, even if there may be client-secret configs in place (seems > possible to have them all, right?). If my understand is right, I think we > should clarify that there won't be any fall-back to the weaker > client-secret once the assertions are configured.
Great observation. Thanks for pointing it out. I've added an info section to mention the same here https://cwiki.apache.org/confluence/display/KAFKA/KIP-1258%3A+Add+Support+for+OAuth+Client+Assertion+to+client_credentials+Grant+Type#:~:text=Runtime%20Behavior%3A%20No,in%20failure%20scenarios. LM1: There are mentions to HttpRequestFormatterFactory as "modified > internal class" but it's a new internal class, let's update to avoid > confusion Updated. Please vote if the modifications look good to you. Thanks, Prabhash On Thu, Feb 19, 2026 at 8:59 PM Lianet Magrans <[email protected]> wrote: > Hi Prabhash, sorry for joining late, just a couple of comments: > > LM0: Regarding the fall-back mechanism (from client assertions to the > weaker client-secret), the KIP describes using it based on configs > (fallback if no assertion configs found), makes sense. But what if the > assertions are configured but fail? I expect there won't be any fallback in > that case, even if there may be client-secret configs in place (seems > possible to have them all, right?). If my understand is right, I think we > should clarify that there won't be any fall-back to the weaker > client-secret once the assertions are configured. > LM1: There are mentions to HttpRequestFormatterFactory as "modified > internal class" but it's a new internal class, let's update to avoid > confusion > > Thanks! > Lianet > > > On Fri, Feb 13, 2026 at 10:04 AM Prabhash Kumar <[email protected] > > > wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
