Information on device security

Meshblu gives you the ability to secure access to registered devices by allowing a device to have configured permission whitelists. The lists will contain the UUIDs of devices that will be granted access or banned from communicating with the secured device.


The primary means of identifying a device is by a UUID and a Token. The UUID and Token are created on device registration. When connecting to Meshblu, devices will be authenticated with their UUID and Token.

> POST /authenticate HTTP/1.1
> User-Agent: curl/7.39.0
> Host:
> Accept: */*
> X-MESHBLU-UUID: 022faeec-84da-47ee-a2b8-bc68a87863a1
> X-MESHBLU-TOKEN: 5edfd22157e3f4fbe5281461c3e1a28f0e8a1782
< HTTP/1.1 204 No Content
< Access-Control-Allow-Origin: *
< Date: Wed, 18 May 2016 01:34:17 GMT
< Etag: W/"4-N6YlnMDB2uKZp4Zkid/wvQ"
< X-Meshblu-Code: 204
< X-Meshblu-Response-Id: 2ea90542-9a71-4879-85b3-4373ea353244
< X-Meshblu-Status: No Content
< X-Powered-By: Express


When a device doesn't have an owner, it is in an unclaimed (public) state. The device and its properties are searchable by authenticated resources on the same network. The device can then be claimed (see the claim API). Once a device is claimed (owned), it will not be visible publicly except to the owner of the device. Setting the owner property of a device to a UUID will grant that UUID full access to the device.


Deprecation Warning

The special meaning of owner will be removed in a future version of Meshblu. Whitelists will be the exclusive means of configuring device access.


You can control different access levels to your device by using the various whitelist properties.
See Whitelists 2.0 for more details.


In the above scenario Device A will allow Device B to send it messages by including Device B in the message.from whitelist.


In the above scenario Device A will not allow Device B to send it messages, since only Device C is in the message.from whitelist.