Hi Kirk -- thanks for the KIP! Having concrete implementations out-of-the-box will be very helpful.
> As seen in this diagram, the login callback is executed on the client and the validate callback is executed on the broker. There was no diagram when I looked. Maybe there is a broken link or something? > The name of the implementation class will be org.apache.kafka.common.security.oauthbearer.internals.secured.OAuthBearerLoginCallbackHandler I think the internals package was meant for non-public stuff Most of it seems that way, although the "unsecured" implementation is in there -- but that's maybe a grey area since it isn't meant to be used in production scenarios and is mostly leveraged in unit tests. Perhaps move the proposed class into a "o.a.k.c.s.oauthbearer.secured" package? Then any implementation details beyond the public stuff can live under the "...internals.secured" package that you mentioned? The same comment applies to the validator callback handler class. I'm confused by loginRetryMaxWaitMs and loginRetryWaitMs. The former has "Max" in the name, but only the description of the latter mentions it being a max amount of time? Are the descriptions incorrect or perhaps reversed? > Ensure the encoding algorithm isn't none and matches what the expected algorithm expecting "expected algorithm expecting" some kind of grammar issue? Thanks again -- very exciting! Ron On Fri, Aug 13, 2021 at 3:53 PM Kirk True <k...@mustardgrain.com> wrote: > Hi all! > > I have created a new KIP for a new OAuth/OIDC related authentication > feature. > > This task is to provide a concrete implementation of the interfaces > defined in KIP-255 to allow Kafka to connect to an OAuth / OIDC identity > provider for authentication and token retrieval. While KIP-255 provides an > unsecured JWT example for development purposes, this will fill in the gap > and provide a production-grade implementation. > > Here's the KIP: > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=186877575 > > Thanks! > Kirk
