🚨 Kafka Error Guide: 'GroupAuthorizationException' Not Authorized to Access Group

Exact Error Message

A consumer that can authenticate but lacks a group ACL fails when it tries to join its consumer group:

[2026-06-29 10:22:47,889] ERROR [Consumer clientId=inventory-consumer-1,
groupId=inventory-workers] Unexpected error from SyncGroup
(org.apache.kafka.clients.consumer.internals.AbstractCoordinator)

org.apache.kafka.common.errors.GroupAuthorizationException: Not authorized to access
group: inventory-workers
    at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.onJoinPrepare

The broker authorizer logs the matching denial on the Group resource:

[2026-06-29 10:22:47,884] INFO Principal = User:inventory-consumer is Denied operation =
Read from host = 10.0.6.77 on resource = Group:LITERAL:inventory-workers for request =
JoinGroup (kafka.authorizer.logger)

Related phrasings include “Group authorization failed” and “Not authorized to access group”, thrown for JoinGroup, SyncGroup, OffsetFetch, and OffsetCommit requests.

What the Error Means

GroupAuthorizationException means the consumer authenticated fine and may even have topic Read access, but it has no Read ACL on the consumer group resource it is trying to use. In Kafka, the consumer group is itself a protected resource. Joining a group, committing offsets, and fetching committed offsets all require Read on Group:<group.id>. Default-deny applies: without a matching ACL, the operation is rejected.

A complete consumer therefore needs three grants: Read and Describe on the topic(s), and Read on the group. Operators frequently grant the topic ACLs and forget the group one, producing exactly this exception even though the topic is readable.

Common Causes

• Missing group Read ACL for the consumer’s group.id — the most common cause.
• Wrong or unexpected group.id: a framework default (e.g. console-consumer-12345, or a Spring/Connect-generated id) that no ACL covers.
• Resource pattern mismatch: a PREFIXED group ACL that does not match the literal group name, or a case difference.
• Principal mismatch between the authenticated identity and the principal the group ACL was written for (DN mapping, short names).
• Per-instance group ids where each consumer uses a unique group not covered by a wildcard or prefix ACL.

How to Reproduce the Error

Run a consumer with topic access but no ACL on its group:

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

kafka-console-consumer.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --topic inventory --from-beginning \
  --consumer.config /tmp/consumer.properties

The consumer fails to join with GroupAuthorizationException: Not authorized to access group: inventory-workers, even when it can describe the topic.

Diagnostic Commands

All commands below are read-only.

# List ACLs scoped to a specific group
kafka-acls.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --command-config /etc/kafka/admin.properties \
  --list --group inventory-workers

# List everything granted to the consumer principal
kafka-acls.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --command-config /etc/kafka/admin.properties \
  --list --principal User:inventory-consumer

# Confirm the exact group.id the client actually uses
grep -E 'group.id' /tmp/consumer.properties

# See the precise denial: principal, operation, group resource
sudo journalctl -u kafka --since "15 min ago" | grep -iE "Group:.*is Denied"

# Inspect existing consumer groups to confirm naming
kafka-consumer-groups.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --command-config /etc/kafka/admin.properties --list

The denial line’s resource = Group:LITERAL:<name> shows the exact group name and pattern type the broker checked — compare it to your ACLs.

Step-by-Step Resolution

1. Read the denial line to confirm the exact group name and operation (Read on JoinGroup/OffsetFetch).
2. Confirm the real group.id. Frameworks sometimes override it; the value the broker logs is authoritative.
3. List group ACLs with kafka-acls.sh --list --group <name>. If none match, the group Read grant is missing.
4. Check pattern type. A PREFIXED ACL must actually prefix the group name; a LITERAL ACL must match exactly, including case.
5. Verify the principal matches the consumer’s authenticated identity (mind DN mapping and the User: prefix).
6. Grant Read on the group to the consumer principal (operator/mutating step), alongside the topic Read+Describe it already needs.
7. Restart the consumer and confirm it joins and commits offsets without further denials.

Prevention and Best Practices

• Treat the group as a first-class resource in your ACL-as-code: every consumer gets topic Read+Describe and group Read.
• Use stable, predictable group.id values, and consider PREFIXED group ACLs for fleets that share a naming convention.
• Avoid random per-instance group ids in secured clusters unless covered by a prefix ACL.
• Standardize principal mapping so consumer identities map cleanly to ACL principals.
• Alert on Group: denials in the authorizer log to catch a forgotten group grant before rollout completes. The free incident assistant can spot a missing group Read from the denial line.

Related Errors

• TopicAuthorizationException — topic Read/Write denied; often co-occurs when both grants are missing.
• AuthorizationException — the generic parent class.
• ClusterAuthorizationException — cluster-scoped operations denied.
• SaslAuthenticationException — login itself failed; group authorization never ran.

Frequently Asked Questions

My consumer can read the topic but not join. Why? Topic Read and group Read are separate ACLs. You have the topic grant but not the group one. Add Read on Group:<group.id>.

What group.id is actually being checked? The one in the broker denial line. Frameworks (Connect, Streams, Spring) may set or override it, so trust the log over your config assumption.

Do Kafka Streams apps need group ACLs? Yes. Streams uses an internal consumer group named after application.id and needs Read on it, plus several internal topics.

Why does a PREFIXED ACL not match my group? Either the prefix does not actually lead the group name, or the case differs. Pattern matching is exact and case-sensitive.

Can a super user skip this? Yes. Principals in super.users bypass all ACL checks, including group access.