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