🚨 Kafka Error Guide: 'TopicAuthorizationException' Not Authorized to Access Topics

Exact Error Message

A client that authenticates but lacks topic permissions fails when it tries to produce, consume, or even fetch metadata:

[2026-06-29 13:05:12,672] ERROR [Producer clientId=events-producer] Aborting producer
batches due to fatal error (org.apache.kafka.clients.producer.internals.Sender)

org.apache.kafka.common.errors.TopicAuthorizationException: Not authorized to access
topics: [user-events]
    at org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:271)

The broker authorizer logs the corresponding denial against the Topic resource:

[2026-06-29 13:05:12,668] INFO Principal = User:events-producer is Denied operation =
Write from host = 10.0.6.30 on resource = Topic:LITERAL:user-events for request =
Produce (kafka.authorizer.logger)

Related variants include “Not authorized to access topics: […]” for Read, Write, and Describe, and consumers seeing the same exception during metadata fetch.

What the Error Means

TopicAuthorizationException is the topic-scoped subclass of AuthorizationException. The principal authenticated successfully but has no ACL granting the requested operation on the named topic. Kafka authorization is default-deny, so a topic with no matching ACL denies everyone except super.users.

A subtle point: even describing a topic requires the Describe operation. A producer needs Write and Describe; a consumer needs Read and Describe (and separately Read on its group). If only Write is granted, the client may still fail on the metadata request because it cannot Describe the topic. The exception can also list a topic the client never named directly — this happens when the metadata request covers a topic the principal cannot see.

Common Causes

• No topic ACL for the principal — missing equals denied under default-deny.
• Missing Describe: granting only Read or only Write without Describe still fails on metadata.
• Principal mismatch: the authenticated principal (e.g. User:CN=events,OU=apps) differs from the ACL principal (User:events-producer) due to SSL DN mapping.
• Pattern type mismatch: a PREFIXED ACL that does not actually prefix the topic, or a LITERAL ACL with a case/name difference.
• Wrong operation: a consumer granted Write instead of Read, or vice versa.
• Topic name typo in client config so the client requests a topic it has no grant for.

How to Reproduce the Error

Produce to a topic as a principal with no ACL for it:

cat > /tmp/producer.properties <<'EOF'
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="events-producer" password="REDACTED";
ssl.truststore.location=/etc/kafka/ssl/truststore.jks
ssl.truststore.password=changeit
EOF

kafka-console-producer.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --topic user-events --producer.config /tmp/producer.properties <<< "hello"

The producer aborts with TopicAuthorizationException: Not authorized to access topics: [user-events].

Diagnostic Commands

All commands below are read-only.

# List ACLs scoped to the specific topic
kafka-acls.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --command-config /etc/kafka/admin.properties \
  --list --topic user-events

# List all ACLs granted to the failing principal
kafka-acls.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --command-config /etc/kafka/admin.properties \
  --list --principal User:events-producer

# Confirm the precise denial line (operation, topic, pattern)
sudo journalctl -u kafka --since "15 min ago" | grep -iE "Topic:.*is Denied"

# Verify how SSL cert DNs map to principals
grep -E 'ssl.principal.mapping.rules' /etc/kafka/server.properties

# Confirm the topic name and that it exists
kafka-topics.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --command-config /etc/kafka/admin.properties --describe --topic user-events

The denial’s operation = and resource = Topic:LITERAL:<name> fields tell you the exact missing permission and the pattern type the broker matched against.

Step-by-Step Resolution

1. Read the denial line. Note whether the missing operation is Write, Read, or Describe, and the exact topic name and pattern type.
2. List the topic’s ACLs with kafka-acls.sh --list --topic <name>. If empty, the grant is missing entirely.
3. Check for the Describe gap. Producers need Write+Describe; consumers need Read+Describe. A metadata failure usually means Describe is absent.
4. Verify the principal matches the authenticated identity — fix ssl.principal.mapping.rules or rewrite the ACL to the real principal.
5. Confirm the pattern type (LITERAL vs PREFIXED) and case match the topic name.
6. Grant the missing operation (operator/mutating step): Write+Describe for producers, Read+Describe for consumers (plus group Read).
7. Retry and confirm the topic denial no longer appears in the authorizer log.

Prevention and Best Practices

• Always grant Describe alongside Read/Write — the most common cause of a “topic exists but is denied” surprise.
• Manage topic ACLs as code with least privilege; avoid blanket All grants.
• Use consistent ssl.principal.mapping.rules so cert DNs resolve to stable, ACL-friendly principals.
• Prefer PREFIXED ACLs for topic families with a shared naming convention to reduce per-topic churn.
• Alert on Topic: denials in the authorizer log so a forgotten grant is caught before it pages the app team. The free incident assistant can translate the denial line into the exact missing ACL.

Related Errors

• GroupAuthorizationException — consumer group Read denied; consumers often need both.
• AuthorizationException — the generic parent class.
• ClusterAuthorizationException — cluster-scoped operations (idempotent write, create topic) denied.
• SaslAuthenticationException — login failed; authorization never ran.

Frequently Asked Questions

The topic exists and I can produce, but consuming fails. Why? Producing needs Write+Describe; consuming needs Read+Describe plus group Read. The consumer is missing Read (and possibly the group grant).

Why does the error list a topic I never asked for? Metadata requests cover multiple topics. If the principal cannot Describe one of them, it appears in the list even if you did not target it directly.

I granted Read but still get denied. Why? You likely also need Describe. Without it, the client cannot fetch metadata for the topic and fails before reading.

Is this different from AuthorizationException? It is the topic-scoped subclass. Same default-deny root cause, narrowed to a Topic resource.

Do super users need topic ACLs? No. super.users bypass all ACL checks. Use them only for admin/break-glass identities.