Hi Manikumar, You mentioned using Keycloak for integration tests. Everything I'm seeing online suggests that this is best done via Testcontainers. I don't see usage of that anywhere in the project thus far. Would adding a test dependency on Testcontainers be within the scope of this KIP, or should it have its own KIP?
Thanks, Kirk On Thu, Apr 10, 2025, at 2:04 AM, Manikumar wrote: > 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 >
