Page History

...

To keep the Kafka protocol simple, only a single SASL mechanism is allowed for Kafka clients. For protocols other than GSSAPI, client sends the protocol name to the server before any SASL authentication packets are sent. Kafka server checks the first packet and if it is one of the mechanism names that it recognizes including custom protocol names, it switches to that mechanism and starts SASL authentication using subsequent packets. If not, the server defaults to GSSAPI mechanism, treating the first packet as the first GSSAPI authentication packet from the client.

With GSSAPI, the first context establishment packet starts with byte 0x60 (APPLICATION-0 tag) followed by a variable-length encoded size. The first mechanism name packet from Kafka starts with a two-byte version currently set to zero, followed by a mechanism name, making it easy to distinguish from a GSSAPI packet. To avoid conflicts and simplify debugging, Kafka will avoid version numbers for mechanism flow that conflict with the GSSAPI tag in the first byte.

The Kafka Java client implementation skips mechanism flow for GSSAPI to remain interoperable with 0.9.0.x brokers, enabling rolling upgrade of 0.9.0.x clusters which use SASL for replication. Non-Java clients may send mechanism name even for GSSAPI from 0.10.0.0 onwards.

Client flow:

1. If sasl.mechanism is not GSSAPI, send a packet with the mechanism name to the server. Otherwise go to Step 3.
   • Packet Format: | Version (Int16) | Mechanism (String) |
2. Wait for response from the server. If the error code in the response is non-zero, indicating failure, report the error and fail authentication.
3. Perform SASL authentication with the configured client mechanism

Server flow:

...