SASL authentication in Kafka - Step-by-Step Execution

Process Flow - SASL authentication

Client starts connection

↓

Client sends SASL handshake request

↓

Server responds with supported SASL mechanisms

↓

Client selects SASL mechanism and sends authentication data

↓

Server verifies authentication data

↓

If authentication succeeds

→Connection established

↓

If authentication fails

→Connection closed

This flow shows how a Kafka client and server use SASL to securely authenticate before establishing a connection.

Execution Sample

Kafka

props.put("security.protocol", "SASL_PLAINTEXT");
props.put("sasl.mechanism", "PLAIN");
props.put("sasl.jaas.config", "org.apache.kafka.common.security.plain.PlainLoginModule required username=\"user\" password=\"pass\";");

This code configures a Kafka client to use SASL PLAIN authentication with username and password.

Process Table

Step	Action	Client Message	Server Response	Result
1	Client starts connection	Connect request	Await SASL handshake	Connection initiated
2	Client sends SASL handshake request	SASL handshake request	SASL mechanisms list: PLAIN, SCRAM-SHA-256	Client learns mechanisms
3	Client selects mechanism and sends auth data	SASL auth data (username/password)	Verify credentials	Server checks credentials
4	Server verifies authentication	N/A	Authentication success	Connection established
5	If credentials wrong	SASL auth data	Authentication failure	Connection closed

💡 Execution stops when authentication succeeds or fails, ending connection setup.

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
connection_state	Disconnected	Handshake sent	Auth data sent	Authenticated or Closed
sasl_mechanism	None	Received list	Selected PLAIN	Used for auth
auth_status	None	None	Pending	Success or Failure

Key Moments - 2 Insights

Why does the client send a SASL handshake request before authentication data?

The handshake lets the client know which SASL mechanisms the server supports (see execution_table step 2). Without this, the client wouldn't know how to authenticate.

What happens if the server rejects the authentication data?

The server sends an authentication failure response and closes the connection (see execution_table step 5). The client cannot proceed without valid credentials.

Visual Quiz - 3 Questions

Look at the execution_table at step 3, what does the client send?

A SASL auth data (username/password)

B Connection close request

C SASL handshake request

D List of supported mechanisms

💡 Hint

Check the 'Client Message' column at step 3 in the execution_table.

At which step does the server verify the client's credentials?

A Step 2

B Step 4

C Step 3

D Step 1

💡 Hint

Look at the 'Server Response' and 'Result' columns in the execution_table for step 4.

If the client changes the SASL mechanism to SCRAM-SHA-256, which execution_table step would change?

A Step 2 - Server lists mechanisms

B Step 4 - Server verifies authentication

C Step 3 - Client selects mechanism and sends auth data

D Step 5 - Authentication failure

💡 Hint

Changing the mechanism affects what the client sends in step 3.

Concept Snapshot

SASL authentication in Kafka:
- Client starts connection
- Client sends SASL handshake request
- Server replies with supported mechanisms
- Client selects mechanism and sends credentials
- Server verifies and accepts or rejects
Use properties: security.protocol, sasl.mechanism, sasl.jaas.config

Full Transcript

SASL authentication in Kafka starts when the client initiates a connection. The client sends a SASL handshake request to learn which authentication methods the server supports. The server responds with a list of mechanisms like PLAIN or SCRAM-SHA-256. The client then picks one mechanism and sends the authentication data, such as username and password. The server checks these credentials. If they are correct, the connection is established. If not, the server closes the connection. This process ensures secure authentication before any data is exchanged.