MQTT Security Fundamentals: Authentication with Username and Password

In the last post we introduced the very basics of security in MQTT. Today’s post will be digging into more detail, starting with Authentication in MQTT.


Authentication is part of the transport and application level security in MQTT. On the transport level TLS can guarantee authentication of the client to the server using client certificates and of the server to the client validating the server certificate. On the application level the MQTT protocol provides username and password for authentication. Various broker implementations add different mechanisms on top of that. This post will give an overview of authentication in general and which capabilities are built into the MQTT protocol itself. Next week we will have a look at broker authentication approaches.


Authentication is the act of confirming the truth of an attribute of a single piece of data or entity.

According to Wikipedia

This means authentication is used to verify if a person, device or application has the identity they claim to have.

A simple example of that is presented to you when traveling. Before you are able to get on a plane, airport security asks for your passport or ID. Showing the requested ID authenticates you as person. In this case your passport confirms your identity and your name. Everybody could state your name, but only you are able to show the passport as prove of your identity.

Authentication is a process we use everyday without even noticing. Every time you log into your computer you provide a username and a password. The username is your identity and the entry of the password authenticates you as the rightful owner.

MQTT authentication with username/password

When it comes to authentication in MQTT the protocol itself provides username and password fields in the CONNECT message. Therefore a client has the possibility to send a username and password when connecting to an MQTT broker (for more details see the MQTT Essential Part 3: Establishing an MQTT connection)

MQTT Connect message content

The username is a UTF-8 encoded string and the password is binary data with each 65535 bytes max. The rather short non-normative recommendation of 12 characters for a password in the MQTT 3.1 specification was removed in the new 3.1.1 version released last year. The spec also states that a username without password is possible. It’s not possible to just send a password without username.

MQTT Connack contents

When using the built-in username/password authentication, the MQTT broker will evaluate the credential based on the implemented authentication mechanism (more on that in the next post) and return one of the following return codes (a full list of all return codes can be found in the MQTT Essential Part 3: Establishing an MQTT connection).

Return Code Return Code Response
0 Connection Accepted
4 Connection Refused, bad user name or password
5 Connection Refused, not authorized

When setting username and password on the client, it will be sent to the broker in clear text. This would allow eavesdropping by an attacker and is an easy way of obtaining the credentials. The only way to guarantee a completely secure transmission of username and password is to use transport encryption.

So this was the first part about MQTT authentication, in the next post we will look on the different options for implementing the authentication on the broker side by verifying if the provided username/password is valid or by using other attributes like the client identifier for authentication.

We hope you enjoyed part two of the MQTT Security Fundamentals, if you want to get notify as soon as we publish the next post, you can subscribe to our newsletter or RSS feed. You think we have missed some important information? Please tell us, we are always open to questions and suggestions.

Leave a Reply

Your email address will not be published. Required fields are marked *