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