Fix Kafka TopicAuthorizationFailed Errors (2026)

Kafka brokers are refusing client connections because they can’t verify the client’s identity and permissions.

Common Causes:

Incorrect SASL Configuration on Brokers: The brokers aren’t set up to understand the authentication mechanism the clients are using.
- Diagnosis: Check server.properties on your Kafka brokers for sasl.enabled.mechanisms. Ensure it lists the mechanism your clients are configured for (e.g., PLAIN, SCRAM-SHA-256, SCRAM-SHA-512). Also, check authorizer.class.name and ensure it’s set to kafka.security.authorizer.AclAuthorizer or a custom authorizer that’s correctly configured.
- Fix: If sasl.enabled.mechanisms is missing or incorrect, add or correct it. For example, to enable PLAIN authentication:
```
sasl.enabled.mechanisms=PLAIN
```
  This tells the broker which SASL protocols it should advertise and attempt to use for client authentication.
- Why it works: The broker needs to know which authentication "language" to speak with clients. If it doesn’t advertise the correct mechanism, clients will fail to authenticate.
Missing or Incorrect SASL JAAS Configuration on Brokers: Even if the broker advertises a mechanism, its JAAS configuration might be broken, preventing it from loading the necessary authentication plugins.
- Diagnosis: Look for the java.security.auth.login.config JVM argument when starting your Kafka brokers. This points to the JAAS configuration file. Examine this file for the correct entry for KafkaServer.
- Fix: Ensure the JAAS file has an entry like this for KafkaServer (example for PLAIN):
```
KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="your_broker_user"
    password="your_broker_password";
};
```
  Replace your_broker_user and your_broker_password with credentials that Kafka brokers use to authenticate themselves to ZooKeeper or other services if applicable, or configure it for internal broker authentication if that’s your setup. This allows the broker to load and use the specified SASL login module.
- Why it works: JAAS (Java Authentication and Authorization Service) is the underlying framework Kafka uses to plug in different security mechanisms. If the JAAS config is wrong, the SASL modules won’t load, and authentication will fail.
Incorrect SASL Configuration on Clients: Clients are configured to use a SASL mechanism that the brokers don’t support or are not configured for.
- Diagnosis: Check the client’s producer.properties or consumer.properties (or equivalent programmatic configuration) for sasl.mechanism.
- Fix: Ensure sasl.mechanism on the client matches one of the sasl.enabled.mechanisms listed on the broker. For example, if brokers have sasl.enabled.mechanisms=SCRAM-SHA-512, clients must also set sasl.mechanism=SCRAM-SHA-512. This synchronizes the authentication protocol between client and server.
- Why it works: Client and server must agree on the authentication method. Mismatch leads to immediate failure.
Missing or Incorrect JAAS Configuration on Clients: Similar to brokers, clients need their own JAAS configuration to perform SASL authentication.
- Diagnosis: Check the java.security.auth.login.config JVM argument for your client applications. Examine the contents of this file.
- Fix: Ensure the JAAS file has an entry for KafkaClient that matches the sasl.mechanism. For SCRAM-SHA-512:
```
KafkaClient {
    org.apache.kafka.common.security.scram.ScramLoginModule required
    username="your_client_user"
    password="your_client_password";
};
```
  Replace your_client_user and your_client_password with the actual credentials for the client. This enables the client to authenticate using the configured SASL module.
- Why it works: The client needs its own JAAS configuration to present its credentials and perform the SASL handshake correctly.
ZooKeeper Authentication Issues (if using SASL with ZooKeeper): If your Kafka brokers are configured to authenticate with ZooKeeper using SASL, and this fails, it can indirectly lead to authorization errors.
- Diagnosis: Check Kafka broker logs for any errors related to ZooKeeper connections or authentication. Examine the server.properties for zookeeper.connect and any SASL-related properties for ZooKeeper authentication (e.g., zookeeper.sasl.client.username, zookeeper.sasl.client.password or a JAAS config file for ZooKeeper).
- Fix: Ensure the ZooKeeper JAAS configuration on the brokers is correct, and that the credentials used by brokers to connect to ZooKeeper are valid and have the necessary permissions within ZooKeeper to read/write Kafka’s metadata. For example, if using a JAAS file for ZooKeeper:
```
KafkaClient {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="zk_user"
    password="zk_password";
};
```
  This allows brokers to establish a secure and authenticated session with ZooKeeper, which is essential for cluster operation and metadata management.
- Why it works: Kafka relies heavily on ZooKeeper for cluster coordination and storing metadata. If brokers can’t authenticate to ZooKeeper, they can’t operate correctly, leading to downstream errors like TopicAuthorizationFailed.
Incorrect ACLs (Access Control Lists): The user authenticated successfully, but they simply don’t have permission to perform the requested operation on the topic.
- Diagnosis: Use the kafka-acls.sh tool to check existing ACLs. For example, to see ACLs for topic my-topic for user User:my_client_user:
```
kafka-acls.sh --bootstrap-server localhost:9092 --list --topic my-topic --authorizer kafka.authorizer.AclAuthorizer
```
- Fix: Grant the necessary permissions using kafka-acls.sh. For example, to allow User:my_client_user to READ and WRITE to my-topic:
```
kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:my_client_user --operation READ --topic my-topic --authorizer kafka.authorizer.AclAuthorizer
kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:my_client_user --operation WRITE --topic my-topic --authorizer kafka.authorizer.AclAuthorizer
```
  This explicitly grants the authenticated user the rights required to interact with the specified resource.
- Why it works: ACLs are the gatekeepers. If authentication succeeds but authorization fails, it means the identity verified by SASL doesn’t have the specific rights for the requested action.
SSL/TLS Configuration Mismatch (if using SSL/TLS for authentication): If you’re using SSL/TLS for client authentication (mutual TLS), certificate issues or configuration mismatches will prevent authentication.
- Diagnosis: Check broker logs for SSL handshake errors. Verify ssl.client.auth is set to required on brokers if using mTLS. Check if clients are configured with ssl.truststore.location, ssl.truststore.password, ssl.keystore.location, ssl.keystore.password, and ssl.key.password.
- Fix: Ensure that the client’s certificate is trusted by the broker (i.e., signed by a CA that the broker trusts) and that the broker’s certificate is trusted by the client. Correct any path or password errors in the keystore/truststore configurations for both client and broker.
- Why it works: For mTLS, both parties must cryptographically verify each other’s identity using their certificates. Any failure in this chain breaks authentication.

The next error you’ll likely see if all authorization issues are resolved is a LeaderNotAvailable error if the topic itself has no partitions or if partition leaders are in a bad state.