🚨 Kafka Error Guide: 'SaslAuthenticationException: Authentication failed' Invalid Credentials

Exact Error Message

A SASL authentication failure surfaces during the connection handshake, before any produce or consume request succeeds. The client fails fast with a SaslAuthenticationException:

[2026-06-29 11:42:18,003] ERROR [Producer clientId=producer-1] Connection to node -1
(broker-01.kafka.internal/10.0.4.21:9094) failed authentication due to:
Authentication failed: Invalid username or password (org.apache.kafka.clients.NetworkClient)

org.apache.kafka.common.errors.SaslAuthenticationException: Authentication failed:
Invalid username or password

With SCRAM you may instead see a credential-lookup failure on the broker side:

[2026-06-29 11:42:18,001] INFO [SocketServer listenerType=ZK_BROKER] Failed
authentication with /10.0.4.55 (channelId=10.0.4.21:9094-10.0.4.55:51544-7)
(Authentication failed during authentication due to invalid credentials with SASL
mechanism SCRAM-SHA-512) (org.apache.kafka.common.network.Selector)

Related variants for the same root problem include org.apache.kafka.common.errors.AuthenticationException, “Invalid credentials”, and (for Kerberos/GSSAPI) “Unable to obtain password from user” or “Server not found in Kerberos database”.

What the Error Means

SaslAuthenticationException means the TCP and (if configured) TLS layers succeeded, the client offered a SASL mechanism, but the broker rejected the supplied identity. The broker compared the credential the client presented (a username/password for PLAIN or SCRAM, or a Kerberos ticket for GSSAPI) against its configured credential store and found no match. This is strictly an identity check — it is not an authorization (ACL) problem and not a connectivity problem. Authorization failures throw TopicAuthorizationException or AuthorizationException instead, and only after authentication has already passed.

The exception is thrown by the client NetworkClient, but the decision is made by the broker. That is why the broker log is the source of truth for the precise reason.

Common Causes

• Wrong password or username in the client JAAS config — the most common cause, often a stale or rotated secret.
• Mechanism mismatch: client offers PLAIN while the broker only enables SCRAM-SHA-512 (or vice versa). The mechanisms must match exactly.
• SCRAM credentials never created in the metadata/ZooKeeper store with kafka-configs.sh, so there is nothing to match.
• Malformed JAAS string: missing trailing semicolon, wrong LoginModule class, or sasl.jaas.config not set at all.
• Kerberos/GSSAPI issues: expired keytab, clock skew beyond five minutes, wrong service principal name, or a missing krb5.conf.
• Listener uses the wrong protocol: client connects to a SASL_SSL listener with a SASL_PLAINTEXT config, so the handshake never completes cleanly.

How to Reproduce the Error

On a broker that requires SASL, point a client at the SASL listener with a deliberately wrong password:

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

kafka-broker-api-versions.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --command-config /tmp/bad-client.properties

The command fails immediately with SaslAuthenticationException: Authentication failed. Reproducing with a known-bad credential confirms the broker path is reachable and the failure is purely the credential.

Diagnostic Commands

All commands below are read-only inspection.

# Confirm which SASL mechanisms and protocol the listener expects
grep -E 'sasl.enabled.mechanisms|listeners|security.inter.broker' \
  /etc/kafka/server.properties

# Inspect the client JAAS config that is actually in use (look for typos / wrong module)
grep -E 'sasl.mechanism|security.protocol|sasl.jaas.config' /tmp/bad-client.properties

# List SCRAM users that exist in the credential store (does the user even exist?)
kafka-configs.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --describe --entity-type users --command-config /etc/kafka/admin.properties

# Broker-side reason for the rejection — the authoritative message
sudo journalctl -u kafka --since "10 min ago" | grep -i "Failed authentication"

# For GSSAPI: confirm the keytab principal and expiry
sudo klist -kte /etc/kafka/kafka.keytab

The broker journalctl line tells you whether it was “invalid credentials”, an “unsupported mechanism”, or a Kerberos failure — each points to a different fix.

Step-by-Step Resolution

1. Read the broker log first. The client only says “Authentication failed”. The broker line distinguishes a bad password from an unsupported mechanism or a Kerberos error.
2. Confirm the mechanism matches. Ensure sasl.mechanism on the client is one of the broker’s sasl.enabled.mechanisms. A PLAIN client against a SCRAM-SHA-512-only broker fails here.
3. Verify the user exists in the SCRAM store via kafka-configs.sh --describe --entity-type users. If absent, the credential must be created by an operator (mutating, done separately).
4. Re-issue the correct password in the client sasl.jaas.config. Watch for shell-escaping problems and a missing terminating semicolon on the JAAS string.
5. Check the protocol. Connecting to a SASL_SSL listener requires security.protocol=SASL_SSL plus a valid truststore; a SASL_PLAINTEXT config will be rejected.
6. For GSSAPI, renew the keytab, confirm the principal with klist -kte, and verify NTP keeps clock skew under five minutes.
7. Retry with kafka-broker-api-versions.sh --command-config to validate the fix without producing data.

Prevention and Best Practices

• Store SASL secrets in a secret manager and inject them at deploy time so rotation does not silently leave clients with stale passwords.
• Standardize on a single mechanism (SCRAM-SHA-512 is a good default) across the fleet to eliminate mechanism-mismatch incidents.
• Validate JAAS config in a pre-deploy check — assert the module class, username, and a non-empty password before shipping.
• For Kerberos, monitor keytab expiry and run NTP everywhere; clock skew is a frequent and confusing cause.
• Add a synthetic auth probe using kafka-broker-api-versions.sh from each client network so credential breakage is caught before the app fleet pages. For triage help, the free incident assistant can turn the broker log line into a likely cause.

Related Errors

• TopicAuthorizationException / AuthorizationException — authentication succeeded but the principal lacks ACLs. A different layer entirely.
• SslAuthenticationException / SSL channel closed — failure happens during the TLS handshake, before SASL.
• org.apache.kafka.common.errors.AuthenticationException — the parent class; same identity-rejection meaning.
• GroupAuthorizationException — consumer group access denied after a successful login.

Frequently Asked Questions

Is SaslAuthenticationException an ACL problem? No. It is an identity check. ACL denials raise TopicAuthorizationException or AuthorizationException, and only after authentication passes.

Why does the client only say “Authentication failed” with no detail? Brokers deliberately avoid leaking whether the username or the password was wrong. The full reason is in the broker log via journalctl.

My password is correct but it still fails. Why? Check the mechanism. A correct password offered with PLAIN against a SCRAM-SHA-512 broker still fails. Also confirm the SCRAM credential was actually created in the store.

Does TLS need to work before SASL? On a SASL_SSL listener, yes — the TLS handshake completes first. A truststore problem shows as an SSL error, not a SASL one.

How do I test credentials without producing data? Use kafka-broker-api-versions.sh --bootstrap-server ... --command-config client.properties. It authenticates and lists API versions without writing.