Add Facebook Login to Your App

Authenticating & Authorizing Devices using MQTT with Auth0

MQTT is a lightweight protocol often used for devices to communicate with other systems. It is designed for the publish/subscribe messaging pattern.

Generally speaking there are 3 components:

  1. A publisher of messages.
  2. A subscriber to messages.
  3. A broker that connects one and the other.

There's a notion of topics (a.k.a. as channels or subjects) which messages are associated with. Topics are used to route messages between publishers and subscribers.

The MQTT protocol supports a basic authentication mechanism based on usernames & passwords. These credentials are sent with the CONNECT message.

This article shows an integration between nodejs based MQTT broker: mosca and Auth0. In this example, Auth0 is used to authenticate publishers and subscribers to the broker, and then authorize routing of messages.

mosca is a nodejs based messaging broker that implements other protocols besides MQTT. It offers great extensibility features. It is surprisingly simple to integrate with Auth0.

1. Set up your app in Facebook

Components of the solution

2. Create and enable a connection in Auth0

The Broker

mosca is straightforward to host and can be embedded in other servers. For the purpose of this sample, we simply self-host a mosca server:

This creates a server listening for MQTT messages on port 9999. mosca allows you to override the 3 functions used to authenticate and authorize operations.

In this sample, we are using a very simple module auth0mosca to perform these functions. Auth0 is wired up to mosca.

3. Test the connection

The Auth0Mosca module

This little module provides the 4 functions used by mosca, authenticateWithCredentials, authenticateWithJWT, authorizePublish and authorizeSubscribe:

authenticateWithCredentials uses the OAuth2 Resource Owner Password Credential Grant to authenticate the broker and all connections to it. Each time a publisher or a subscriber send a CONNECT message to the broker the authenticate function is called. In it we call the Auth0 endpoint and forward the device's username/password. Auth0 validates this against its account store (that is the first in the code). If successful, it validates and parses the Access TokenJSON Web Token (JWT) to obtain the device profile and adds it to the client object that represents either the subscriber or the publisher. That's done in the jwt.verify call.

By convention, all devices connected to the broker have an account in Auth0:

Notice that the Device Profile also has a property topics. This is an array with all topics this particular device is allowed to. In the screenshot above, thermostat-1a will be allowed publishing (or subscribing) to topics temperature and config.

The authorizePublish and authorizeSubscribe functions simply check that a particular requested topic is present in this list.

The authenticateWithJWT expects a JWT in the password field. The flow in this case is slightly different:

  1. The publisher & subscriber will obtain a token
  2. They connect to mosca submitting the JWT
  3. mosca validates the JWT
  4. Messages are sent and re-transmitted to subscribers

Publishers and subscribers will obtain the JWT through some means. Notice that the broker doesn't need to communicate with Auth0 anymore. JWTs are self-contained artifacts that can be validated with the secret used to sign them.

Access Facebook's API

The Publisher

For this sample, the publisher is a simple nodejs program that uses the mqtt module, and adds the right credentials:

Of course username & password here will have to match whatever is stored in Auth0.

Facebook Re-Authentication

The subscriber

The subscriber is very similar to the publisher:

Additional Info


This shows how easy it is to use Auth0 in various scenarios. Auth0's user store is being used to manage devices. Of course much more sophisticated authorization rules could be written based on other conditions: time, location, device_id, and so on All these would be very simple to implement, either through additional profile attributes or through Auth0 Rules. This also shows how the flexible Auth0 Profile can be extended to support arbitrary artifacts (such as topics in the example).

Ιt is never a good idea to send credentials (username/password) over unsecured networks. There are other implementations that provide transport level security that would prevent message contents to be revealed. mosca supports TLS as an example. Likely a production deployment would favor this, unless all traffic happens in a closed network.

Next Steps


Many thanks to Matteo Collina for the review of this article, and for building the awesome mosca.