Using MQTT bootstrap auth to authenticate devices without knowin clientID beforehand

[francis.brosnan]

1. Introduction

MyQttHuB bootstrap auth allows to create a set of credentials (userName + password) that allows to authenticate a group of MQTT devices without knowing beforehand clientID that will be used. It optionally supports registering that device to acquire a concrete user that can be configured further.

This type of authentication allows to support the following two general use cases:

a) MQTT devices that does not support configuring clientID: only userName and password.

b) Authenticate and bootstrap a (usually) large set of devices, for which, all of them will use same userName and password, and at connecting time (MQTT CONNECT) a different, and unique, clientID is provided so they are differenciated and handled by your MQTT HUB as independent units.

Case b) also expands by using the “register device” option so you can, for example, register 100 devices using same credentials, and asking the platform to register that device (so they can be configured through the panel and also get access to full features provided MQTT that, for example, needs storage support that can survive across device sessions).

2. How to use bootstrap auth

Mechanism is pretty simple. Here are steps to create your first MQTT bootstrap auth credentials:

1. Go to your MyQTTHub and click on “bootstrap” credentials, then click add:

   

2. Then go to the bootstrap section:

   

3. Now add bootstrap credentials and optionally click on on register device:

   

Now, you can configure these credentials as userName and password at any MQTT device. They will successfully connect to your MQTT HUB as long as they use a different clientID (not registered by a permanent user and not used by any other connected device at your HUB).

3. How a device connected using bootstrap auth works?

Any device using bootstrap auth credentials will work as follows:

1. It will authenticate in case userName and password are correct and clientId provided is not already used by any registered device and not used by any other connected device (without considering how they connected).

2. If a device connects with a bootstrap credentials configured to [register device], then that device will be registered and cleanSession indication will be honoured.

3. In case a device connects for second time (and next), and used bootstrap credentials configured to [register device], then it will be authenticated using regular mechanism (without using bootstrap auth).

   That’s because it was registered the first time it connected. In such case, that device will work as a regular device and in fact, will appear as a device that can be managed at Devices section:

   

4. In case a device successfully connects with bootstrap credentials NOT configured to [register device], then that device will be considered as virtual (same status is acquired when using skip connection replace option) so cleanSession indication is forced to true. That is, all subscriptions and pending messages for this device will be lost after it disconnects.

4. When should I use [register device] option?

It depends on the scenario you want to implement. Here are some hints:

1. Pet vs. Cattle scenario: If you have a large group of devices that only produces data (PUBLISH) and you do not want to handle them individually, you can avoid adding each device one by one at Devices, instead, you add a single bootstrap auth credentials without enabling register device because you don’t care about each device: you only want them to connect and PUBLISH.

2. Apps without clientId configuration ability: in case you want to connect with a MQTT application, broker, etc, that do not have any possibility to configure a fixed clientId but they “bootstrap” it on connect, you can use register device just to make sure when it connects for the second time, it is handled as a device registered (which can be configured and can implement cleanSession).