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