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 > > > > > > > > > > > > > > >
