An order producer and a reporting consumer connect to the same Kafka cluster. TLS protects their network traffic, but Kafka still needs to identify the application behind each connection. The producer should connect as the order service, and the consumer should connect as reporting, even when both run on the same machine.

SASL gives Kafka a framework for establishing those identities. Applications prove who they are through an authentication mechanism, and Kafka uses the resulting identity when checking permissions.

This chapter follows that process from connection setup to an authenticated request, then explains the configuration and operational decisions involved. Examples use Apache Kafka 4.3 in KRaft mode, the Apache Kafka Java clients, and SCRAM authentication over TLS.

SASL, or Simple Authentication and Security Layer, is a framework that lets a protocol use different authentication mechanisms. A mechanism defines the exchange a client uses to prove its identity, including the credentials or cryptographic evidence involved.

Kafka supports mechanisms such as PLAIN, SCRAM, GSSAPI for Kerberos, and OAUTHBEARER. They fit into the same authentication framework, but their credential sources and deployment requirements differ. Selecting SASL does not automatically connect Kafka to your company's identity provider.

For a concrete example, assume the order service has a username and a secret the administrator has provisioned for SCRAM-SHA-256. SCRAM is a password-based challenge-response mechanism: the client proves knowledge of its secret through an exchange with the server. The application does not attach its password to every order record.

The distinction between the framework and the mechanism appears directly in Kafka configuration. The client selects a SASL-capable connection protocol and separately names the mechanism it will use.

These settings must agree with the endpoint the client reaches. A valid password cannot fix a connection to a listener that does not support the selected mechanism.

Kafka exposes two SASL security protocols:

Use SASL_SSL for the examples here. TLS protects the connection and lets the client verify the broker's certificate. SASL then authenticates the client over that protected connection.

SASL_PLAINTEXT does not encrypt Kafka records. Even when a mechanism avoids sending a raw password, that property does not make the subsequent event traffic confidential. A private network also does not provide the same protection as transport encryption.

Two names are easy to confuse: PLAIN is a SASL mechanism, while PLAINTEXT describes an unencrypted transport. A connection using the PLAIN mechanism with SASL_SSL carries the authentication exchange inside TLS. The protocol and mechanism are separate choices.

Our SCRAM example uses server-authenticated TLS without requiring client certificates. The client needs to trust the broker certificate, but it proves its own identity through SASL. A deployment that additionally requires a client certificate has an extra TLS prerequisite before SASL can succeed.

The order service opens a connection to a broker's SASL listener. Before ordinary produce requests can run, the client and broker complete the authentication exchange.

The sequence below shows the main stages for SASL_SSL. It omits protocol-version discovery and groups mechanism-specific messages together so the responsibilities remain clear.

The client names its mechanism during the SASL handshake. The broker may support several mechanisms, but the client uses the one it selected. Do not expect the client to silently choose a different mechanism when its configuration is incompatible.

With current Kafka clients, SASL authentication messages travel through Kafka's SaslAuthenticate exchange. The contents depend on the mechanism. Only after authentication succeeds can the connection proceed with normal application operations.

A principal is Kafka's representation of the authenticated identity. With Kafka's default SCRAM principal handling, the username order-service becomes User:order-service. The User prefix names a principal type; the identity can belong to a service rather than a person.

Authentication normally happens when the client establishes a connection, not once for every record. The client can send many requests over the authenticated connection. A new connection to another broker needs its own authentication, and configured reauthentication can require an established connection to authenticate again.

Suppose the store uses two principals:

The broker can distinguish these services because they authenticate separately. They may share a host, an IP address, or a client library without sharing an identity.

The distinction also holds when application labels change. Setting client.id=order-service labels requests for tracking; it does not prove possession of the order service's credentials. Similarly, group.id=order-reporting names a consumer group. Kafka still needs to decide whether the authenticated principal may use that group.

The diagram separates proving an identity from allowing an operation. Both applications can authenticate successfully while receiving different permissions.

If the producer accidentally starts with reporting's credentials, authentication may succeed. Its write should then fail authorization. The correction is to deploy the intended identity, rather than expand reporting's permissions to make the mistaken deployment work.

SASL itself does not enable Kafka's authorizer or create ACLs. An authorizer evaluates permissions, and ACLs, or access control lists, describe allowed and denied operations on Kafka resources. Configure authorization separately if the cluster must enforce those boundaries.

The identity also has limits. When an order service publishes on behalf of thousands of customers, Kafka authenticates the service connection. A customerId in the event does not mean Kafka authenticated that customer. The application remains responsible for validating the customer's request before publishing the event.

A listener is a named server endpoint that accepts connections. To support SASL, that listener needs a SASL security protocol, enabled mechanisms, and the server-side configuration required to validate credentials.

For this example, assume an existing KRaft cluster has an application listener named CLIENT, advertised at addresses such as broker-1.kafka.example.com:9095. Its protocol mapping includes CLIENT:SASL_SSL. Assume the deployment has already configured broker certificates, advertised hostnames, and client trust for TLS.

The following properties are the SASL portion of that application listener's configuration. They are a fragment for an existing deployment, not a complete broker startup file:

The property names use the lowercase listener and mechanism names. The first property enables SCRAM-SHA-256 on this endpoint. The second supplies its Java login-module configuration.

JAAS, or Java Authentication and Authorization Service, is the Java framework Kafka uses for this configuration. A login module participates in preparing the authentication identity and credentials. Despite the word “Authorization” in JAAS's name, this property does not grant Kafka topic permissions.

The example listener accepts application connections; it is not the listener this broker uses to initiate connections to other brokers. That is why the login-module entry does not contain an outbound broker username and password.

Provisioning the Service Credential

Enabling SCRAM does not create order-service. With Kafka's built-in SCRAM implementation, an authorized administrator must create the credential for that username and mechanism in the KRaft metadata log. The server stores derived SCRAM credential material rather than a plaintext copy of the password.

The application receives the corresponding secret through the deployment's secret-management process. Treat both the application secret and the server-side credential material as sensitive.

Assume the administrator has provisioned order-service for SCRAM-SHA-256 before starting the example client. A credential the administrator provisioned only for SCRAM-SHA-512 would not satisfy this configuration, even if the username were identical. The mechanism is part of the credential setup.

On an existing cluster, credential administration requires a working administrative identity and permission to perform the change. Creating internal credentials for a new cluster also requires planning for startup dependencies. An application username in a properties file cannot establish either of those prerequisites.

Every broker the service may reach must accept the intended mechanism and identity. Internal broker and controller connections have their own listener and credential requirements; configuring CLIENT alone does not configure those paths.

The order service must select the listener's protocol and mechanism, trust its broker certificates, and supply the provisioned credential.

Save the following settings in a protected file such as /etc/order-service/kafka-sasl.properties. Replace the example hostnames, paths, and password placeholders with values from your deployment:

The truststore must contain the trust anchors needed to validate the broker certificates. Keep hostname verification enabled. The SASL password does not replace the broker's TLS identity checks.

The JAAS value includes a login-module class, the required control flag, and mechanism-specific options. Preserve its terminating semicolon. The backslashes continue the value across lines in a Java properties file; if constructing a Java Properties object directly, supply the complete JAAS value as one string.

The placeholder text has no special meaning to Kafka. Arrange for your deployment or application to supply real secrets safely. Do not assume that writing an environment-variable reference into an arbitrary properties file makes Kafka expand it. Protect generated configuration files and avoid printing their contents during startup diagnostics.

These connection properties also apply to the Apache Kafka Java consumer and Admin client. A producer still needs serializers and application settings. A consumer needs deserializers and, for ordinary group-based consumption, its group configuration. Non-Java libraries may expose different names and formats for the same authentication requirements.

Configuration Scope

Kafka Java clients can receive JAAS settings through sasl.jaas.config or a static JAAS file that the JVM configuration selects. When both are present, the client property takes precedence.

Using client-specific configuration makes identity ownership easier to follow. If one process contains a producer and a consumer that need different service identities, each can receive its own properties. A shared process does not require a shared Kafka credential.

Keep the mechanism explicit. The Java client's default mechanism is GSSAPI, so supplying a SCRAM login module while omitting sasl.mechanism can make the client try the wrong authentication mechanism.

Verify the service with its own credentials. An administrator successfully connecting to the same broker does not prove that the administrator has correctly provisioned order-service.

Assume orders.placed exists and User:order-service has permission to describe it. With the Kafka 4.3 distribution and a supported Java runtime installed, run this command from the Kafka installation directory:

A successful response demonstrates that this tool completed the connection and authentication process and could perform the requested Kafka operation. It does not prove that the application can write to every partition. Verify its intended produce or consume behavior as well.

When the check fails, identify the stage before changing credentials or permissions:

Read the client error together with the relevant broker log. A general authentication failure may not reveal whether the username is unknown or the password is wrong. Do not depend on detailed public errors to distinguish those cases.

If the service connects initially but fails after reaching another broker, compare the brokers' listener configurations and advertised endpoints. A bootstrap address is the first contact, not a guarantee that the remaining connections will work.

Treat credential failures as deployment or identity problems that need diagnosis. Repeatedly restarting an application with the same invalid secret cannot correct it and may create a large volume of failed authentication attempts. Surface the error without logging passwords, bearer tokens, or full JAAS values.

Kafka clients maintain multiple connections and reconnect when brokers restart or leadership changes. Each fresh connection needs credentials that the receiving broker currently accepts.

Suppose order-service authenticates, then an administrator changes its SCRAM password. The application may continue using an already authenticated connection while still holding the old secret. When the client replaces that connection, authentication with the old secret fails.

The diagram shows why steady traffic alone cannot validate a credential change:

For Kafka's built-in SCRAM store, updating the password for a username and mechanism replaces that credential; it does not automatically preserve two valid passwords for a gradual rollout. Coordinate the server-side update with the application's credential deployment and verify fresh connections.

If the rollout requires an overlap period, one option is a temporary second service identity with the intended permissions. Move application instances to it, verify their new connections, then retire the old identity and its permissions. This adds administrative work and changes the principal that logs and policies show, so account for both during the transition.

Kafka also supports SASL reauthentication through a configured session lifetime. Whether and when it occurs depends on broker settings and client support. Do not assume that refreshing a credential in a secret store automatically refreshes a running client's authentication state, or that deleting a credential immediately closes every established connection.

During credential compromise, address both future authentication and already established access. That may require permission changes or closing affected connections in addition to replacing the secret. Verify the result using the deployment's actual client behavior.

An authentication outage can interrupt processing without deleting Kafka data. A consumer may resume from its committed offsets once it reconnects, provided the records remain available. For a producer that lost an earlier connection after sending a request, the write outcome may still be uncertain. Authentication restores access; the application's normal retry and duplicate-handling rules govern recovery.

SASL establishes a connection's identity through a selected authentication mechanism. The listener, credential store, and client configuration must agree, while TLS protects the exchange and subsequent traffic.

Successful authentication creates a principal; authorization determines what that principal may do. Use separate service identities, verify with the application's own credentials, and test fresh connections during credential changes. A working session does not guarantee that the next authentication attempt will succeed.