Hi all! I've published an update KIP, which includes:
1. Clarity and corrections for all of the feedback 2. Use of the mock-oauth2-server library for integration testing 3. Reduced the public exposure of some of the internals (assertion creation, file caching, etc.) I'd like to call a vote soon, so if you have additional feedback, please let me know. Thank you for your feedback and help! Kirk On Fri, Apr 25, 2025, at 12:26 PM, Kirk True wrote: > Hi Lianet, > > On Fri, Apr 25, 2025, at 10:03 AM, Lianet M. wrote: > > Hey Kirk, thanks for the updates. Ack on the responses related to the > > custom validators behaviour (LM3) and nbf (LM4), makes sense to me. > > > > LM6. Related to testing. Have we considered using a mock Oauth server > > instead of the real auth frameworks/servers mentioned above? (There seems > > to be a few libraries out there) > > I will look into a "mock" OAuth server options. > > > LM7. Related to supporting live file rotation for keys and assertions: it’s > > a bit confusing, since all the configs mention “it's advisable, but not > > required, to have a mechanism…”, but I get (from the Rejected Alternatives > > actually) that we do support live rotation (with a “less dynamic mechanism > > to detect file changes”). Should we clarify it in the related *.file > > configs, that it does support live rotation? > > Yes, this is a very clumsy section. When it comes to client implementations, > KIPs are open to interpretation. > > The main idea came from talking to the librdkafka team. They were a little > hesitant about being required to use a dynamic file watcher service because > implementations for that vary across the matrix of languages and OSes they > support. > > Any suggestions as how to handle that in the KIP? > > Thanks, > Kirk > > > Thanks! > > > > On Thu, Apr 24, 2025 at 7:46 PM Kirk True <k...@kirktrue.pro> wrote: > > > > > Hi Manikumar, > > > > > > Update on the use of Keycloak for integration testing. It turns out it > > > doesn't support the JWT Bearer grant type anyway, so it can't be used for > > > testing the new code :( > > > > > > I also looked into Apache Shiro, but it also doesn't support the JWT > > > Bearer grant type. > > > > > > Thanks, > > > Kirk > > > > > > On Tue, Apr 22, 2025, at 11:31 AM, Kirk True wrote: > > > > Also, Keycloak is MIT licensed. Is that OK to include in Kafka? > > > > > > > > On Tue, Apr 22, 2025, at 10:49 AM, Kirk True wrote: > > > > > 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 > > > > > > > > > > > > > > > > >
