Kafka supports four SASL mechanism families: GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256 and SCRAM-SHA-512, and OAUTHBEARER. If you have no Kerberos and no token issuer, SCRAM over TLS is a sensible default. PLAIN is acceptable only with TLS and a proper credential source. Choose by the identity system you already run.
What Kafka supports
The Kafka security overview lists GSSAPI, PLAIN, SCRAM-SHA-256 and SCRAM-SHA-512, and OAUTHBEARER. It also notes that security in Kafka is optional, and that clusters can mix authenticated and unauthenticated clients. That mix is the first thing to rule out.
SASL can run over a plaintext or a TLS transport, named SASL_PLAINTEXT and SASL_SSL. With SASL_SSL, TLS must also be configured. For anything that carries real credentials, use SASL_SSL.
GSSAPI (Kerberos)
Pick it when your organisation already runs Kerberos and has people who operate it. You get central identity and ticket-based login. You also inherit Kerberos operations, including keytabs and clock sync. If nobody on your team runs Kerberos today, this is a heavy thing to adopt for Kafka alone.
PLAIN
PLAIN is a simple username and password mechanism. The Kafka documentation says it should be used only with TLS so clear passwords never cross the wire unencrypted. It also notes that the default implementation keeps usernames and passwords in the JAAS configuration file, and that from version 2.0 you can plug in callback handlers that read credentials from an external source or verify against an external authentication server.
In short, PLAIN is a transport for a password, and the quality of your setup depends on where the passwords live and how they rotate.
SCRAM
SCRAM is a family of challenge and response mechanisms defined in RFC 5802, intended to address the concerns of plain password mechanisms. In Kafka, credentials are stored in the cluster metadata log and are created with kafka-configs.sh or kafka-storage.sh. The documented default iteration count is 4096 when none is given, and a random salt is created if you do not set one.
For a team without an external identity provider, this keeps credentials inside the cluster and avoids sending the password itself. It still needs TLS for confidentiality of the rest of the session.
OAUTHBEARER
OAUTHBEARER suits teams that already issue tokens from an identity provider and want short-lived credentials. The Kafka documentation describes separate non-production and production setups. Read the production notes before you ship, since the non-production example is only a starting point.
A decision guide
- Run Kerberos already: GSSAPI.
- Have a token issuer and want short-lived credentials: OAUTHBEARER.
- Want self-contained credentials with no extra system: SCRAM over SASL_SSL.
- Must support legacy clients that only speak PLAIN: PLAIN over SASL_SSL, with credentials from an external source.
Whatever you pick, pair it with ACLs. Authentication tells Kafka who is calling. ACLs decide what they may do.
Quick check
Can I use SASL_PLAINTEXT in production?
The documentation allows it, but credentials and data then travel unencrypted. For production, SASL_SSL is the safer choice.
Is SCRAM stored outside Kafka?
No. In current Kafka the SCRAM credentials are stored in the cluster metadata log.
Sources
Last reviewed: 19 October 2026.
