16.2. Using OAuth 2.0 token-based authentication

1. The Kafka client requests an access token from the authorization server using a client ID and credentials, and optionally a refresh token. Alternatively, the client may authenticate using a username and a password.
2. The authorization server generates a new access token.
3. The Kafka client authenticates with the Kafka broker using the SASL OAUTHBEARER mechanism to pass the access token.
4. The Kafka broker validates the access token by calling a token introspection endpoint on the authorization server using its own client ID and secret.
5. A Kafka client session is established if the token is valid.

1. The Kafka client authenticates with the authorization server from the token endpoint, using a client ID and credentials, and optionally a refresh token. Alternatively, the client may authenticate using a username and a password.
2. The authorization server generates a new access token.
3. The Kafka client authenticates with the Kafka broker using the SASL OAUTHBEARER mechanism to pass the access token.
4. The Kafka broker validates the access token locally using a JWT token signature check, and local token introspection.

1. The Kafka client authenticates with the Kafka broker using the SASL OAUTHBEARER mechanism to pass the long-lived access token.
2. The Kafka broker validates the access token by calling a token introspection endpoint on the authorization server, using its own client ID and secret.
3. A Kafka client session is established if the token is valid.

1. The Kafka client authenticates with the Kafka broker using the SASL OAUTHBEARER mechanism to pass the long-lived access token.
2. The Kafka broker validates the access token locally using a JWT token signature check and local token introspection.

1. The Kafka client passes a clientId as a username and a secret as a password.
2. The Kafka broker uses a token endpoint to pass the clientId and secret to the authorization server.
3. The authorization server returns a fresh access token or an error if the client credentials are not valid.

4. The Kafka broker validates the token in one of the following ways:

   1. If a token introspection endpoint is specified, the Kafka broker validates the access token by calling the endpoint on the authorization server. A session is established if the token validation is successful.
   2. If local token introspection is used, a request is not made to the authorization server. The Kafka broker validates the access token locally using a JWT token signature check.

1. The Kafka client passes a username and password. The password provides the value of an access token that was obtained manually and configured before running the client.

2. The password is passed with or without an $accessToken: string prefix depending on whether or not the Kafka broker listener is configured with a token endpoint for authentication.

   1. If the token endpoint is configured, the password should be prefixed by $accessToken: to let the broker know that the password parameter contains an access token rather than a client secret. The Kafka broker interprets the username as the account username.
   2. If the token endpoint is not configured on the Kafka broker listener (enforcing a no-client-credentials mode), the password should provide the access token without the prefix. The Kafka broker interprets the username as the account username. In this mode, the client doesn’t use a client ID and secret, and the password parameter is always interpreted as a raw access token.

3. The Kafka broker validates the token in one of the following ways:

   1. If a token introspection endpoint is specified, the Kafka broker validates the access token by calling the endpoint on the authorization server. A session is established if token validation is successful.
   2. If local token introspection is used, there is no request made to the authorization server. Kafka broker validates the access token locally using a JWT token signature check.

Procedure

1. Specify a listener in the Kafka resource with an oauth authentication type.

   Example listener configuration with OAuth 2.0 authentication

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Kafka
   spec:
     kafka:
       # ...
       listeners:
         - name: tls
           port: 9093
           type: internal
           tls: true
           authentication:
             type: oauth
         - name: external3
           port: 9094
           type: loadbalancer
           tls: true
           authentication:
             type: oauth
         #...

2. Configure the OAuth listener depending on the authorization server and validation type:

   • Configuring fast local JWT token validation
   • Configuring token validation using an introspection endpoint
   • Including additional configuration options
3. Apply the changes to the Kafka configuration.

4. Check the update in the logs or by watching the pod state transitions:

   oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
   oc get pod -w

   The rolling update configures the brokers to use OAuth 2.0 authentication.

Procedure

1. Add the client library with OAuth 2.0 support to the pom.xml file for the Kafka client:

   <dependency>
    <groupId>io.strimzi</groupId>
    <artifactId>kafka-oauth-client</artifactId>
    <version>0.15.0.redhat-00010</version>
   </dependency>

2. Configure the client depending on the OAuth 2.0 authentication method:

   • Example client credentials configuration using the client secret
   • Example password grants configuration
   • Example access token configuration
   • Example refresh token configuration

   For example, specify the properties for the authentication method in a client.properties file.

3. Input the client properties for OAUTH 2.0 authentication into the Java client code.

   Example showing input of client properties

   Properties props = new Properties();
   try (FileReader reader = new FileReader("client.properties", StandardCharsets.UTF_8)) {
     props.load(reader);
   }

4. Verify that the Kafka client can access the Kafka brokers.

Procedure

1. Create a client secret and mount it to the component as an environment variable.

   For example, here we are creating a client Secret for the Kafka Bridge:

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Secret
   metadata:
    name: my-bridge-oauth
   type: Opaque
   data:
    clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw 

   1

   1

   The clientSecret key must be in base64 format.

2. Create or edit the resource for the Kafka component so that OAuth 2.0 authentication is configured for the authentication property.

   For OAuth 2.0 authentication, you can use the following options:

   • Client ID and secret
   • Client ID and client assertion
   • Client ID and refresh token
   • Access token
   • Username and password
   • TLS

   For example, here OAuth 2.0 is assigned to the Kafka Bridge client using a client ID and secret, and TLS:

   Example OAuth 2.0 authentication configuration using the client secret

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth 

   1

   
       tokenEndpointUri: https://<auth_server_address>/<path_to_token_endpoint> 

   2

   
       clientId: kafka-bridge
       clientSecret:
         secretName: my-bridge-oauth
         key: clientSecret
       tlsTrustedCertificates: 

   3

   
         - secretName: oauth-server-cert
           pattern: "*.crt"

   1

   Authentication type set to oauth.

   2

   URI of the token endpoint for authentication.

   3

   Certificates stored in X.509 format within the specified secrets for TLS connection to the authorization server.

   In this example, OAuth 2.0 is assigned to the Kafka Bridge client using a client ID and the location of a client assertion file, with TLS to connect to the authorization server:

   Example OAuth 2.0 authentication configuration using client assertion

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth
       tokenEndpointUri: https://<auth_server_address>/<path_to_token_endpoint>
       clientId: kafka-bridge
       clientAssertionLocation: /var/run/secrets/sso/assertion 

   1

   
       tlsTrustedCertificates:
         - secretName: oauth-server-cert
           pattern: "*.crt"

   1

   Filesystem path to the client assertion file used for authenticating the client. This file is typically added to the deployed pod by an external operator service. Alternatively, use clientAssertion to refer to a secret containing the client assertion value.

   Here, OAuth 2.0 is assigned to the Kafka Bridge client using a service account token:

   Example OAuth 2.0 authentication configuration using the service account token

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth
       accessTokenLocation: /var/run/secrets/kubernetes.io/serviceaccount/token 

   1

   1

   Path to the service account token file location.

   Depending on how you apply OAuth 2.0 authentication, and the type of authorization server, there are additional configuration options you can use:

   Additional configuration options

   # ...
   spec:
     # ...
     authentication:
       # ...
       disableTlsHostnameVerification: true 

   1

   
       accessTokenIsJwt: false 

   2

   
       scope: any 

   3

   
       audience: kafka 

   4

   
       connectTimeoutSeconds: 60 

   5

   
       readTimeoutSeconds: 60 

   6

   
       httpRetries: 2 

   7

   
       httpRetryPauseMs: 300 

   8

   
       includeAcceptHeader: false 

   9

   1

   (Optional) Disable TLS hostname verification. Default is false.

   2

   If you are using opaque tokens, you can apply accessTokenIsJwt: false so that access tokens are not treated as JWT tokens.

   3

   (Optional) The scope for requesting the token from the token endpoint. An authorization server may require a client to specify the scope. In this case it is any.

   4

   (Optional) The audience for requesting the token from the token endpoint. An authorization server may require a client to specify the audience. In this case it is kafka.

   5

   (Optional) The connect timeout in seconds when connecting to the authorization server. The default value is 60.

   6

   (Optional) The read timeout in seconds when connecting to the authorization server. The default value is 60.

   7

   (Optional) The maximum number of times to retry a failed HTTP request to the authorization server. The default value is 0, meaning that no retries are performed. To use this option effectively, consider reducing the timeout times for the connectTimeoutSeconds and readTimeoutSeconds options. However, note that retries may prevent the current worker thread from being available to other requests, and if too many requests stall, it could make the Kafka broker unresponsive.

   8

   (Optional) The time to wait before attempting another retry of a failed HTTP request to the authorization server. By default, this time is set to zero, meaning that no pause is applied. This is because many issues that cause failed requests are per-request network glitches or proxy issues that can be resolved quickly. However, if your authorization server is under stress or experiencing high traffic, you may want to set this option to a value of 100 ms or more to reduce the load on the server and increase the likelihood of successful retries.

   9

   (Optional) Some authorization servers have issues with client sending Accept: application/json header. By setting includeAcceptHeader: false the header will not be sent. Default is true.

3. Apply the changes to the resource configuration of the component.

4. Check the update in the logs or by watching the pod state transitions:

   oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
   oc get pod -w

   The rolling updates configure the component for interaction with Kafka brokers using OAuth 2.0 authentication.