Hi, Kirk, Thanks for the KIP. A few comments below.
JR1. OAuthBearerConfigurable.configure(): Could you describe the possible values for saslMechanism? Is it always OAUTHBEARER? JR2. If sasl.oauthbearer.jwt.retriever.class is not configured, what other configs lead to the selection of JwtBearerJwtRetriever? JR3. If sasl.oauthbearer.jwt.validator.class is not configured, how do we choose which built-in class to use? JR4. Could we document what type can be returned for Object in the following? public interface AssertionJwtTemplate extends OAuthBearerConfigurable { /** * Returns a map containing zero or more header values. * * @returns Values to include in the JWT header */ Map<String, Object> header(); /** * Returns a map containing zero or more JWT payload claim values. * * @returns Values to include in the JWT payload */ Map<String, Object> payload(); JR5. "alg": RS256 : Should RS256 be quoted? JR6. "Step 2 is to create the JWT payload from the claims provided to {@link #create(Map)}": The parameter for create() is not a Map. JR7. For the new configuration table, could we document the type of each new config? JR8. Could we describe the format of sasl.oauthbearer.assertion.file? JR9. sasl.oauthbearer.assertion.private.key.passphrase: In the "Mutually exclusive configuration" part, it should say "If the sasl.oauthbearer.assertion.file is used, this will be ignored.", right? JR10. sasl.oauthbearer.assertion.expiration.minutes and sasl.oauthbearer.assertion.not.before.minutes: Why are they in minutes instead of seconds? JR11. "Two of the JAAS options (clientId and clientSecret) for the existing client_credentials grant type are deprecated." Should we include sasl.oauthbearer.scope too? Thanks, Jun On Fri, Mar 14, 2025 at 11:52 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