Configure Clients for SASL/OAUTHBEARER Authentication in Confluent Platform
To configure Confluent Platform and Kafka clients to use SASL/OAUTHBEARER authentication with TLS encryption when connecting to Confluent Server brokers, add the following properties to your client’s properties file, replacing the placeholders with your actual values:
sasl.mechanism=OAUTHBEARER
security.protocol=SASL_SSL
ssl.truststore.location=<path/to/client.truststore.jks>
ssl.truststore.password=<truststore-password>
sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler
sasl.login.connect.timeout.ms=15000 # optional
sasl.oauthbearer.token.endpoint.url=<idp-token-endpoint>
sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
clientId="<client-id>" \
clientSecret="<client-secret>" \
scope="<scope>"; # optional
The optional scope parameter defines the level of access the client is requesting, but is required if your identity provider does not have a default scope or your groups claim is linked to a scope.
For Kafka Java clients supporting SASL OAUTHBEARER, allow specific IdP endpoints by setting the following configuration property:
org.apache.kafka.sasl.oauthbearer.allowed.urls=<idp_jwks_url>,<idp_token_url>,...
This property specifies a comma-separated list of allowed IdP JWKS (JSON Web Key Set) and token endpoint URLs. Use * (asterisk) as the value to allow any endpoint.
org.apache.kafka.sasl.oauthbearer.allowed.urls=*
You should consult the specific Kafka client and IdP documentation for the exact interpretation and security implications of such a broad setting.
Java applications should set this property as a JVM system property when launching the application:
-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls=<idp_jwks_url>,<idp_token_url>,...
For other clients (for example, Python, Go, .NET) that are built on librdkafka, these clients use different property names and configuration mechanisms. So, refer to specific client library documentation for the equivalent OAuthBEARER configuration properties.
For details on the client configuration properties used in this example, see Client Configuration Properties for Confluent Platform.
Run kafka-console-consumer with SASL/OAUTHBEARER
The following example runs the kafka-console-consumer command-line tool with SASL/OAUTHBEARER authentication. The --consumer.config flag points to the client.properties file that contains the SASL/OAUTHBEARER properties:
kafka-console-consumer \
--bootstrap-server <host>:9092 \
--topic <topic-name> \
--consumer.config <path/to/client.properties>
When using SASL/OAUTHBEARER authentication, the Kafka client libraries typically obtain OAuth tokens automatically using the configured client ID, client secret, and token endpoint URL. After successful authentication, the client consumes messages from the specified topic and prints them to the console (stdout).
Tip
For clients using Azure User Assigned Managed Identity (UAMI) to obtain Entra ID tokens without static client credentials, see Configure Azure User Assigned Managed Identity OAuth for Confluent Platform. UAMI eliminates the need to manage client IDs and secrets by using Azure’s built-in identity management. UAMI is supported for Java, Python, .NET, JavaScript, Go, and C/C++ clients.