- Un
publisher
de messages. - Un
subscriber
de messages. - Un
broker
qui relie l’un et l’autre.
topics
(également appelés channels
ou subjects
) auxquels les messages sont associés. Les sujets sont utilisés pour acheminer les messages entre les éditeurs et les abonnés.
Le protocole MQTT prend en charge un mécanisme d’authentification de base basé sur des usernames
et des passwords
. Ces identifiants sont envoyés avec le message CONNECT
.
Cet article montre une intégration entre un agent MQTT basé sur nodejs : mosca et Auth0. Dans cet exemple, Auth0 est utilisé pour authentifier les publishers
et subscribers
auprès de l’agent, puis pour autoriser l’acheminement des messages.

Composants de la solution
L’agent
mosca est facile à héberger et peut être intégré à d’autres serveurs. Pour les besoins de cet exemple, nous nous contentons d’héberger nous-mêmes un serveur mosca :auth0mosca
, pour exécuter ces fonctions. Auth0 est connecté à mosca.
Le module Auth0Mosca
Ce petit module fiournit les quatre fonctions utilisées par mosca,authenticateWithCredentials
, authenticateWithJWT
, authorizePublish
et authorizeSubscribe
:
authenticateWithCredentials
utilise OAuth2 Propriétaire de ressource, attribution de mot de passe et d’identifiant pour authentifier l’agent et toutes les connexions qui lui sont adressées. Chaque fois qu’un publisher
ou un subscriber
envoie un message CONNEXION à l’agent, la fonction authenticate
est appelée. Nous y appelons le point de terminaison Auth0 et lui transmettons leusername
/password
. Auth0 le valide par rapport à sa base de données de comptes (c’est le premierrequest.post
dans le code). En cas de succès, il valide et analyse le jeton Web JSON () pour obtenir le profil de l’appareil et l’ajoute à l’objet client
qui représente soit le subscriber
ou le publisher
. Cela se produit dans l’appel jwt.verify
.
Par convention, tous les appareils connectés à l’agent ont un compte dans Auth0.
Remarquez que le profil de l’appareil a également une propriété topics
. Il s’agit d’un tableau contenant tous les sujets auxquels cet appareil particulier est autorisé à accéder. Dans la capture d’écran ci-dessus, le thermostat-1a
sera autorisé à publier (ou à s’abonner) aux sujets temperature
et config
.
Les fonctionnalités authorizePublish
et authorizeSubscribe
vérifient simplement qu’un sujet particulier demandé est présent dans cette liste.
authenticateWithJWT
attend un JWT dans le champ password
. Dans ce cas, le flux est légèrement différent :
- L’éditeur et l’abonné obtiendront un jeton
- Ils se connectent à
mosca
en soumettant le JWT mosca
valide le JWT- Les messages sont envoyés et retransmis aux abonnés

L’éditeur
Pour cet exemple, l’éditeur est un simple programme nodejs qui utilise le modulemqtt
, et ajoute les bons identifiants :
username
et le password
devront correspondre à ceux stockés dans Auth0.
L’abonné
L’abonné est très similaire à l’éditeur :Résumé
Cela montre à quel point il est facile d’utiliser Auth0 dans différents scénarios. Le magasin d’utilisateurs d’Auth0 est utilisé pour gérer les appareils. Bien entendu, des règles d’autorisation beaucoup plus sophistiquées pourraient être élaborées sur la base d’autres conditions : heure, lieu, device_id, etc. Toutes ces règles seraient très simples à mettre en œuvre, soit au moyen d’attributs de profil supplémentaires, soit au moyen de règles. Cela montre également comment le profil Auth0 flexible peut être étendu pour prendre en charge des artefacts arbitraires (tels que lestopics
dans l’exemple).
Pour en savoir plus sur les règles, consultez Règles d’Auth0.
Il n’est jamais bon d’envoyer des identifiants (username
/password
) sur des réseaux non sécurisés. Il existe d’autres implémentations qui fournissent une sécurité au niveau du transport qui empêcherait le contenu des messages d’être révélé. mosca prend en charge TLS par exemple. Il est probable qu’un déploiement en production privilégie cette solution, à moins que tout le trafic se fasse dans un réseau fermé.