MQTT est un protocole léger souvent utilisé par les appareils pour communiquer avec d’autres systèmes. Il est conçu pour le modèle de messagerie publication/abonnement. Vous pouvez en savoir plus sur MQTT sur Wikipedia. D’une manière générale, il y a trois composantes :Documentation Index
Fetch the complete documentation index at: https://docs-staging.auth0-mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
- Un
publisherde messages. - Un
subscriberde messages. - Un
brokerqui 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 à
moscaen soumettant le JWT moscavalide 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é.