Page History

...

The proposed change is largely composed of a pair of AuthenticateCallbackHandler implementations: one to login on the client and one to validate on the broker.

As seen show in this the above diagram, the login callback is executed on the client and the validate callback is executed on the broker.

...

The name of the implementation class will be org.apache.kafka.common.security.oauthbearer.internals.secured.OAuthBearerLoginCallbackHandler and it will accept instances of org.apache.kafka.common.security.oauthbearer.OAuthBearerTokenCallback and org.apache.kafka.common.security.auth.SaslExtensionsCallback. The fully-qualified class name will be provided to the client's sasl.login.callback.handler.class configuration.

Because the HTTP call made to the OAuth/OIDC provider may time out or transiently fail, there will be a retry mechanism that waits between attempts. The number of attempts that are made (including the first attempt) are configured via the loginAttempts configuration setting. The retry will use an exponential backoff approach; the first attempt to connect to the HTTP endpoint will be made immediately. If that first attempt fails, a second attempt will first wait a configurable number of milliseconds–loginRetryWaitMs–before trying again. If that second attempt fails, the wait time (loginRetryWaitMs) will be doubled before a third attempt. This pattern repeats up to loginAttempts. However, there is also a configurable maximum wait time between attempts–loginRetryMaxWaitMs–such that loginRetryWaitMs <= loginRetryMaxWaitMs, regardless of the number of attempts: min(currentRetryWaitMs, loginRetryMaxWaitMs).

There are several configuration options for this callback handler:

• tokenEndpointUri: OAuth issuer token endpoint URI

• clientId: supports OAuth clientcredentials grant type

• clientSecret: supports OAuth's clientcredentials grant

• scope: optional scope to reference in the call to the OAuth server

• scopeClaimName: optional override name of the scope claim; defaults to scope
• subClaimName: optional override name of the sub claim; defaults to scope
• loginConnectTimeoutMs: optional value in milliseconds for HTTPS connect timeout; defaults to 10000
• loginReadTimeoutMs: optional value in milliseconds for HTTPS read timeout; defaults to 10000
• loginAttempts: optional number of attempts to make to connect to the OAuth/OIDC identity provider; defaults to 3
• loginRetryMaxWaitMsloginRetryWaitMs: optional value in milliseconds for the amount of time to wait between HTTPS call attempts; defaults to 250
• loginRetryMaxWaitMs: optional value in milliseconds for the maximum wait between HTTPS call attempts. The HTTP calls retry mechanism uses an exponential backoff approach up to the number defined by loginAttempts but not more than loginRetryWaitMs; defaults to 250loginRetryWaitMs: optional value in milliseconds for the maximum amount of time to wait before HTTPS call attempts; defaults to to 10000

Here's an example of the configuration as a part of a Java properties file:

...

1. Parse the JWT into separate header, payload, and signature sections

2. Base-64 decode the header and payload

3. Extract the necessary claims for validationEnsure the encoding algorithm isn't none and matches what the expected algorithm expecting

4. Match the key ID (kid) specified in the JWT header to a JWK ID from the JWK Set

5. Ensure the encoding algorithm (alg from the header) isn't none and matches the expected algorithm for the JWK ID

6. Encode the header and payload sections of the original encoded JWT access token using the public key from the JWK and ensure it matches the signature section of the JWT

7. Extract the scope, iat, exp, and sub claims as these are needed by the OAuthBearerToken object to be passed to the OAuthBearerValidatorCallback.

8. Optional claim validation that ensures that issuer, audience, or other claims match a given value

...