Enhanced Authentication in MQTT 5 Explained

For two decades, MQTT clients authenticated to the Server the same way: send a username, send a password, hope the Server accepts. That worked for the IoT prototypes of the 2000s. It does not work for modern industrial systems where credentials rotate, identities federate, and a plain-text password traveling over the wire is a security incident waiting to happen.

MQTT 5.0 fixed this with Enhanced Authentication — a proper authentication framework that supports SASL-style challenge-response flows, multi-step exchanges, token-based authentication (OAuth 2.0), Kerberos, and re-authentication during a live session. It is one of the most important security upgrades MQTT v5.0 brought over MQTT 3.1.1.

This article explains how Enhanced Authentication works in MQTT 5: the AUTH control packet, the Authentication Method and Authentication Data properties, the message flows for SCRAM, OAUTHBEARER, and other common methods, and how re-authentication keeps long-lived sessions secure without disconnecting.

For broader MQTT 5.0 context, see our MQTT 5 New Features overview and MQTT Authentication and Authorization Guide.

What Enhanced Authentication is in one paragraph

Enhanced Authentication is the SASL-style authentication framework introduced in MQTT 5.0 (OASIS Standard, March 2019) that lets clients and Servers exchange authentication data through multi-step challenge-response flows. It uses a new control packet type — AUTH (Control Packet Type 15) — combined with two new properties on the CONNECT and CONNACK packets: Authentication Method (Property 0x15) identifying the chosen authentication mechanism, and Authentication Data (Property 0x16) carrying the cryptographic exchange data. Enhanced Authentication enables modern authentication mechanisms — SCRAM, OAUTHBEARER (OAuth 2.0), GSSAPI/Kerberos, EXTERNAL (TLS client certificates) — without leaking plain credentials, and supports re-authentication mid-session for credential rotation in long-lived connections.

Why Enhanced Authentication exists

MQTT 3.1.1 supported only basic authentication: the CONNECT packet carried a UTF-8 Username and (optionally) a binary Password field. The Server compared them against its credential store and accepted or rejected the connection. This worked but had serious limitations:

Limitation 1: Credentials sent in plain

Without TLS, basic auth sends the password over the wire as plaintext. With TLS, the password is encrypted in transit but still sent to the Server as plaintext after TLS termination. A compromised Server, a misconfigured logging system, or a TLS-terminating proxy could capture every password.

Limitation 2: No multi-step flows

Challenge-response authentication protocols like SCRAM (Salted Challenge Response Authentication Mechanism) need multiple round trips between client and Server to prove identity without revealing the password. MQTT 3.1.1’s CONNECT-then-CONNACK flow doesn’t allow this.

Limitation 3: No standardized federated authentication

Modern enterprise authentication uses tokens (OAuth 2.0 access tokens), Kerberos tickets, or X.509 certificates issued by a centralized identity provider. MQTT 3.1.1 had no mechanism to integrate with these systems beyond mapping them into the simple Username/Password fields, which is awkward at best.

Limitation 4: No re-authentication

Long-lived MQTT connections (industrial telemetry connections often run for weeks) couldn’t refresh credentials without disconnecting. When an OAuth access token expires, the only option was tear down the connection and reconnect — losing message context, retained connection state, in-flight QoS 1/2 messages.

Enhanced Authentication addresses all four limitations. It provides a generic framework adaptable to any SASL-compatible authentication mechanism, supports multi-step flows, integrates with federated identity systems, and allows credential refresh mid-session.

The AUTH control packet (type 15)

MQTT 5.0 adds AUTH as Control Packet Type 15 — the only packet type in MQTT that exists solely for authentication purposes. Per OASIS MQTT v5.0 Section 3.15:

Fixed Header:
  Byte 1: 11110000 (Type 15, Reserved flags 0000)
  Byte 2+: Variable Byte Integer remaining length

Variable Header:
  Reason Code (1 byte)
  Properties (Variable Byte Integer length + properties)

Payload: None (AUTH has no payload)

The Reason Code identifies the AUTH packet’s purpose:

The Reason Code makes AUTH the state machine driver for multi-step authentication. The client and Server bounce AUTH packets back and forth carrying Reason Code 0x18 until one of them either succeeds (Server sends CONNACK or AUTH with 0x00) or fails (closes connection with appropriate Reason Code).

Sender direction

AUTH packets can flow in either direction:

• Client → Server: continue authentication, or request re-authentication
• Server → Client: continue authentication, send a challenge

This bidirectional pattern is what distinguishes MQTT 5’s authentication from the rigid CONNECT-then-CONNACK flow of MQTT 3.1.1.

Authentication Method and Authentication Data properties

Enhanced Authentication relies on two new properties:

Authentication Method (Property 0x15)

A UTF-8 string identifying the SASL-compatible authentication mechanism in use. The client sets this in the CONNECT packet to declare which mechanism it wants to use. The Server either accepts (proceeds with that method) or rejects with appropriate Reason Code.

Common Authentication Method values:

The string must match a method the Server supports. If the Server doesn’t support the requested method, it returns CONNACK with Reason Code 0x8C (Bad authentication method).

Authentication Method is immutable for the duration of the Network Connection — once selected at CONNECT time, the same method must be used for all subsequent AUTH exchanges, including re-authentication. Switching methods requires a new connection.

Authentication Data (Property 0x16)

Binary Data carrying the cryptographic content exchanged during authentication. Its format depends entirely on the Authentication Method — for SCRAM-SHA-256 it’s a UTF-8 string with specific delimiters; for GS2-KRB5 it’s binary GSSAPI tokens; for OAUTHBEARER it’s a structured token blob.

Both client and Server can include Authentication Data in CONNECT, CONNACK, and AUTH packets as the multi-step exchange progresses. The Server interprets the bytes according to the chosen Authentication Method.

If the chosen mechanism requires no data exchange (e.g., EXTERNAL relying on TLS client certificates), Authentication Data may be empty or absent.

The basic challenge-response flow

The simplest Enhanced Authentication flow has just two exchanges. Here’s a SCRAM-SHA-256 example (simplified):

Client → Server: CONNECT
  Authentication Method: "SCRAM-SHA-256"
  Authentication Data: client-first-message (username + client nonce)

Server → Client: AUTH (Reason Code 0x18 — Continue authentication)
  Authentication Method: "SCRAM-SHA-256"
  Authentication Data: server-first-message (server nonce + salt + iteration count)

Client → Server: AUTH (Reason Code 0x18 — Continue authentication)
  Authentication Method: "SCRAM-SHA-256"
  Authentication Data: client-final-message (proof of password knowledge)

Server → Client: CONNACK (Reason Code 0x00 — Success)
  Authentication Method: "SCRAM-SHA-256"
  Authentication Data: server-final-message (server signature)

After this exchange, both client and Server have proven their identity to each other (mutual authentication), and a shared session key may have been derived for further use. The plaintext password was never sent over the wire — only cryptographic proofs derived from it.

The Server’s CONNACK with Reason Code 0x00 finalizes the authentication. From there, normal MQTT operation begins — the client publishes, subscribes, and processes messages.

Failure path

If authentication fails at any step, the appropriate party sends DISCONNECT or CONNACK with a failure Reason Code:

Failed authentication terminates the Network Connection. The client must reconnect from scratch with potentially adjusted credentials or method.

Common authentication methods

SCRAM (Salted Challenge Response Authentication Mechanism)

Defined in IETF RFC 5802, SCRAM is the modern replacement for plaintext password authentication. Variants include SCRAM-SHA-1, SCRAM-SHA-256, and SCRAM-SHA-512 (the larger the hash, the stronger the security but the more compute).

How SCRAM works (simplified):

1. Client sends username and a random client nonce
2. Server returns a server nonce, the user’s salt, and an iteration count
3. Client computes a cryptographic proof using the password, salt, and iteration count — proving it knows the password without sending it
4. Server validates the proof and sends its own signature (mutual authentication)

SCRAM is excellent for password-based authentication where plaintext exposure must be eliminated. The Server stores the user’s salted password hash (not the plaintext), and even if the credential store is compromised, the attacker doesn’t get plaintext passwords.

OAUTHBEARER (OAuth 2.0 bearer tokens)

Defined in IETF RFC 7628, OAUTHBEARER lets MQTT clients authenticate using OAuth 2.0 access tokens. The flow:

1. Client obtains an access token from an OAuth 2.0 authorization server (separate process, before connecting to MQTT)
2. Client connects to MQTT Server, presents the token as Authentication Data
3. MQTT Server validates the token against the authorization server (or its public key for self-contained JWT tokens)
4. Server returns CONNACK Success if the token is valid and authorized

OAUTHBEARER is the standard for cloud-native MQTT deployments — IoT platforms, enterprise integration. The MQTT Server delegates identity management to the OAuth provider (Auth0, Okta, Azure AD, AWS Cognito, etc.) and only validates that incoming tokens are legitimate and authorized.

Critically, OAuth tokens have expiration times. This is where MQTT 5’s re-authentication feature becomes essential — long-lived MQTT connections need to refresh tokens without disconnecting.

GS2-KRB5 (Kerberos via GSSAPI)

Defined in IETF RFC 5801 and 4121, GS2-KRB5 brings Kerberos authentication to MQTT. Used in:

• Enterprise environments where Kerberos already authenticates users to corporate resources
• Active Directory integrated deployments
• High-security industrial systems with Kerberos infrastructure

GS2-KRB5 is more operationally complex than OAUTHBEARER but provides single sign-on integration with existing Kerberos realms.

EXTERNAL (TLS client certificates and others)

Defined in IETF RFC 4422, EXTERNAL delegates authentication to a mechanism outside MQTT — most commonly TLS client certificates. The flow is simple:

1. Client establishes TLS connection presenting a client certificate
2. Server validates the certificate via TLS handshake
3. Client sends CONNECT with Authentication Method “EXTERNAL” and (optionally) Authentication Data containing identity information
4. Server uses the TLS-validated identity for authorization, returns CONNACK Success

EXTERNAL is appropriate for industrial IoT installations using PKI for device identity — every device has its own certificate, validated by mutual TLS, with the certificate’s subject identifying the device.

Re-authentication mid-session

This is one of the most important features Enhanced Authentication unlocks. In MQTT 3.1.1, refreshing credentials required disconnecting and reconnecting. MQTT 5.0 allows re-authentication on a live connection.

When to re-authenticate

Common scenarios:

• OAuth 2.0 access token approaching expiration — refresh before it expires
• Credential rotation policies require periodic re-authentication
• Security event detected — Server requires re-verification
• Long-lived industrial telemetry connections spanning weeks/months
• Session continuity requirements that can’t afford a disconnect

Re-authentication flow

The client initiates re-authentication by sending an AUTH packet:

Client → Server: AUTH (Reason Code 0x19 — Re-authenticate)
  Authentication Method: same as original (must match)
  Authentication Data: fresh authentication data

Server → Client: AUTH (Reason Code 0x18 — Continue authentication) [optional]
  ... multi-step exchange if required ...

Server → Client: AUTH (Reason Code 0x00 — Success)

The connection remains open throughout. Subscriptions stay active. In-flight QoS 1/2 messages aren’t disrupted. The client’s new credentials replace the old ones for future authorization decisions.

Critical rules

• The Authentication Method must match the original method used at CONNECT time. You can’t switch from SCRAM-SHA-256 to OAUTHBEARER mid-session.
• The re-authentication must complete successfully for the session to continue. If re-authentication fails, the Server closes the connection.
• The client can decide when to re-authenticate based on its own logic (e.g., token expiration timers).
• The Server can also force re-authentication by sending its own AUTH packet — though this is less commonly implemented.

AUTH Reason Codes

Per OASIS MQTT v5.0 Section 3.15.2.1, AUTH packets carry one of three Reason Codes:

That’s the entire AUTH Reason Code set. Authentication failures are signaled via DISCONNECT or CONNACK Reason Codes, not via the AUTH packet itself.

CONNACK and DISCONNECT use Reason Codes from a broader set. Authentication-related codes you’ll encounter:

For complete Reason Code coverage, see our MQTT 5 Reason Codes Reference.

Security benefits over basic authentication

Enhanced Authentication brings several concrete improvements:

Server support and deployment

Enhanced Authentication is part of the MQTT 5.0 specification, which means Servers that claim MQTT 5.0 conformance must support the AUTH packet structure. However, which Authentication Methods a Server actually supports varies significantly:

Deployment guidance:

1. Check Server documentation before designing the client side — not every Server supports every Authentication Method
2. Use SCRAM-SHA-256 or stronger for password-based scenarios where Enhanced Auth is supported
3. Use OAUTHBEARER for cloud-native deployments integrating with identity providers
4. Use EXTERNAL with TLS client certificates for industrial IoT device fleets where PKI is appropriate
5. Fall back to basic auth only when Enhanced Auth isn’t available, and always require TLS

Client library support

Most major MQTT 5.0 client libraries support Enhanced Authentication:

• Eclipse Paho (Java, C, Python) — explicit AUTH packet support
• HiveMQ MQTT Client (Java, JavaScript) — full Enhanced Auth API
• MQTTnet (.NET) — supports AUTH and custom authentication handlers
• node-mqtt (Node.js) — supports Authentication Method/Data via options
• paho-mqtt (Python) — limited Enhanced Auth support, varies by version

For each client, the specific API differs but the protocol-level flow is identical.

Practical implementation example

A simplified Python pseudocode example showing SCRAM-SHA-256 authentication:

python

# Client connects with SCRAM-SHA-256
client.username_pw_set(None)  # Don't use basic auth
client.tls_set(...)  # Always use TLS

# Generate client first message
client_nonce = generate_nonce()
client_first_message = f"n,,n={username},r={client_nonce}"

properties = Properties(PacketTypes.CONNECT)
properties.AuthenticationMethod = "SCRAM-SHA-256"
properties.AuthenticationData = client_first_message.encode()

client.connect(broker, port=8883, properties=properties)

# Server responds with AUTH packet containing server-first-message
# Client computes client-final-message
# Client sends AUTH packet with client-final-message  
# Server validates and sends CONNACK with success

The actual SCRAM-SHA-256 cryptographic operations (computing client/server proofs, applying salt + iteration) are handled by a SASL library or the MQTT client library’s built-in implementation. The application code typically just sets the Authentication Method and lets the library handle the flow.

Common errors and troubleshooting

Frequently asked questions

What is Enhanced Authentication in MQTT 5?

Enhanced Authentication is a SASL-style authentication framework introduced in MQTT 5.0 (OASIS Standard, March 2019) that supports multi-step challenge-response authentication flows. It uses a new control packet — AUTH (Control Packet Type 15) — combined with Authentication Method and Authentication Data properties to enable modern authentication mechanisms like SCRAM, OAUTHBEARER (OAuth 2.0), GSSAPI/Kerberos, and EXTERNAL (TLS client certificates). It replaces MQTT 3.1.1’s basic username/password authentication for security-sensitive deployments.

What is the AUTH packet in MQTT 5?

The AUTH packet is Control Packet Type 15 in MQTT 5.0, introduced specifically for authentication exchanges. It carries a Reason Code (0x00 Success, 0x18 Continue authentication, 0x19 Re-authenticate) plus Authentication Method and Authentication Data properties. AUTH packets can flow in either direction (client-to-Server or Server-to-client) and enable multi-step authentication flows impossible in MQTT 3.1.1’s rigid CONNECT-then-CONNACK pattern.

What authentication methods does MQTT 5 support?

MQTT 5’s Enhanced Authentication framework is method-agnostic — any SASL-compatible mechanism can be used as long as both client and Server support it. Common methods include: SCRAM-SHA-256 and SCRAM-SHA-512 (password-based, no plaintext exchange), OAUTHBEARER (OAuth 2.0 bearer tokens, IETF RFC 7628), GS2-KRB5 (Kerberos via GSSAPI), and EXTERNAL (TLS client certificates or other external authentication). Server support varies — check your Server’s documentation for which methods are actually implemented.

How does SCRAM authentication work in MQTT 5?

SCRAM (Salted Challenge Response Authentication Mechanism, RFC 5802) authenticates without sending plaintext passwords. The flow: (1) Client sends username and a random nonce in CONNECT, (2) Server responds with AUTH containing its nonce, the user’s salt, and iteration count, (3) Client sends AUTH with a cryptographic proof of password knowledge, (4) Server returns CONNACK with success and its own signature. The plaintext password is never sent — both parties mathematically prove they know the same secret without exchanging it.

What is re-authentication in MQTT 5?

Re-authentication is the ability to refresh credentials on a live MQTT connection without disconnecting. The client sends an AUTH packet with Reason Code 0x19 (Re-authenticate), and the same multi-step authentication flow occurs as during initial connection. Critically, the Authentication Method must match the original method used at CONNECT — you can’t switch methods mid-session. Re-authentication is essential for long-lived MQTT connections using OAuth tokens that expire periodically, allowing token refresh without losing subscriptions or in-flight messages.

Can I use OAuth 2.0 with MQTT 5?

Yes. MQTT 5 supports OAuth 2.0 via the OAUTHBEARER authentication method (IETF RFC 7628). The client obtains an access token from an OAuth 2.0 authorization server (separately, before connecting), then presents the token as Authentication Data in CONNECT. The MQTT Server validates the token (either with the authorization server or via its public key for JWT tokens) and accepts the connection if valid. Because OAuth tokens have expiration times, MQTT 5’s re-authentication feature is essential for long-lived OAuth-authenticated sessions.

What is the difference between basic authentication and Enhanced Authentication?

Basic authentication (MQTT 3.1.1 style) uses a simple Username and Password field in CONNECT — the password travels to the Server in plaintext (relying on TLS for transit encryption). Enhanced Authentication (MQTT 5) uses a SASL-style framework supporting cryptographic proofs (no plaintext), multi-step exchanges, federated identity (OAuth, Kerberos), token-based authentication, and mid-session re-authentication. Enhanced Authentication is the modern, security-best-practice approach; basic auth is the simple legacy option suitable only for low-security deployments.

What Reason Codes apply to AUTH packets?

The AUTH packet uses exactly three Reason Codes: 0x00 (Success) — authentication completed, 0x18 (Continue authentication) — more exchange needed, and 0x19 (Re-authenticate) — client requesting re-authentication on active session. Authentication failures use CONNACK or DISCONNECT Reason Codes instead — common failure codes are 0x87 (Not authorized), 0x8A (Banned), and 0x8C (Bad authentication method).

Do I need TLS if I use Enhanced Authentication?

Yes, you should still use TLS. Enhanced Authentication protects credentials during the authentication exchange, but it doesn’t encrypt MQTT messages themselves once authentication completes. Without TLS, all PUBLISH messages, topic names, and payloads flow as plaintext over the network. TLS is the network-layer security; Enhanced Authentication is the authentication-layer security. Both layers serve different purposes and should be used together for any production deployment.

Which MQTT Servers support Enhanced Authentication?

MQTT 5.0-compliant Servers all support the AUTH packet structure, but specific Authentication Method support varies. Full support: HiveMQ (SCRAM, OAUTHBEARER, custom), EMQX (SCRAM-SHA-256, OAuth 2.0, JWT, LDAP). Limited support: Mosquitto (AUTH packet but few built-in methods), VerneMQ (community plugins). Custom mechanisms: AWS IoT Core uses custom authorizers rather than standard SASL methods; Azure IoT Hub uses SAS tokens and X.509 certificates. Check your Server’s documentation before designing client authentication.

Can the Authentication Method change during a session?

No. Per OASIS MQTT v5.0 Section 4.12, the Authentication Method selected at CONNECT time is immutable for the duration of the Network Connection. Re-authentication (Reason Code 0x19) must use the same method. To change methods, the client must disconnect and reconnect with a new CONNECT using the desired Authentication Method.