Hi Kirk,

Thanks for the KIP. This will be a valuable addition for implementing the
JWT Bearer Grant Type in OAuth 2.0 authorization flow.

I had a few comments and suggestions:

1. The “Rejected Alternatives” section notes that Java's WatchService won't
be used. Could you clarify when a dynamic mechanism for detecting file
changes would be required?
 Is this aimed at supporting automatic key rotation on the client side?

2. We've previously encountered CVEs related to unsafe file access. Should
we consider introducing an allowlist mechanism for file-based configs such
as:
    - sasl.oauthbearer.assertion.private.key.file
    - sasl.oauthbearer.assertion.file
Similar to the existing ALLOWED_SASL_OAUTHBEARER_URLS_CONFIG?

3. I assume these changes work seamlessly with:
    - The existing RefreshingLogin mechanism on the client
    - Broker reauthentication via connections.max.reauth.ms
Could you please confirm?

4. I recommend including Keycloak-based integration tests to ensure
compatibility with standard OAuth providers.

5. We currently lack user-facing documentation for OAuth. As part of the
implementation, it would be helpful to include:
    - Example client configurations
    - A full end-to-end usage guide for the JWT bearer grant flow in Kafka


Thanks,
Manikumar

On Sat, Mar 15, 2025 at 12:23 AM Kirk True <k...@kirktrue.pro> wrote:

> Hi all,
>
> I would like to start a discussion for KIP-1139: Add support for OAuth
> jwt-bearer grant type:
>
> https://cwiki.apache.org/confluence/x/uIxEF
>
> The proposal is twofold:
>
> * Add support for the OAuth 2.0 JWT Bearer grant type to avoid use of
> plaintext client secrets
> * Promote internal APIs for public use by this and future OAuth work
>
> Thanks!
> Kirk

Reply via email to