Corriger MQTT connexion refusée : non autorisé

« MQTT connection refused: not authorized » signifie que le broker a reçu votre paquet CONNECT, l'a compris et a décidé que ce client ne pouvait pas se connecter. En MQTT 3.1.1, il s'agit du code de retour CONNACK 5 ; en MQTT 5, du reason code 0x87. Ce guide vous donne une check-list pas à pas pour trouver la cause d'une connexion MQTT refusée pour non-autorisation, des identifiants et client ID aux confusions de ports et aux comptes propres à chaque broker, et montre comment tester chaque étape en ligne de commande.

Ce que « Not Authorized » vous apprend réellement

L'erreur est plus instructive qu'il n'y paraît. Pour la recevoir, plusieurs choses doivent déjà fonctionner :

Le DNS a résolu l'hôte du broker.
La connexion TCP, et TLS le cas échéant, a été établie.
Le broker a analysé un paquet CONNECT valide.
La version du protocole a été acceptée.

Le réseau fonctionne donc. Le problème porte sur l'identité ou les permissions. Selon l'outil, la formulation diffère :

Outil	Message typique
mosquitto_pub / mosquitto_sub	`Connection error: Connection Refused: not authorised.`
Paho Python 2.x	`reason_code` vaut `Not authorized` dans `on_connect`
MQTT.js	`Connection refused: Not authorized` (`err.code === 5`) ou reason code 135 en MQTT 5
Nœud MQTT de Node-RED	Le statut affiche « connecting » et le journal signale connection refused, not authorized

Un code voisin mérite d'être distingué tôt. Le code de retour 4 (0x86 en MQTT 5) signifie « bad user name or password » : les identifiants eux-mêmes ne correspondent pas. Le code 5 (0x87) est plus large : le broker refuse ce client pour une raison d'autorisation. Certains brokers renvoient aussi 5 pour un mauvais mot de passe : traitez donc les deux comme un problème d'identité à vérifier, mais lisez le code exact. Le guide des codes de retour CONNACK MQTT explique chaque valeur.

La check-list de dépannage « Not Authorized »

Suivez ces étapes dans l'ordre. La plupart des cas sont résolus à l'étape 3.

Confirmez à quel broker vous vous connectez. Affichez l'hôte et le port que votre code utilise réellement à l'exécution, pas ceux que vous croyez configurés. Variables d'environnement et fichiers de configuration se surchargent fréquemment.
Recopiez les identifiants. Collez à nouveau le nom d'utilisateur et le mot de passe depuis la page d'identifiants du broker. Vérifiez les espaces en début ou fin de chaîne, les sauts de ligne introduits par le copier-coller et l'inversion entre nom d'utilisateur et mot de passe.
Utilisez le client ID associé aux identifiants. Beaucoup de brokers MQTT managés lient un client ID au compte émis. Si votre code génère un ID aléatoire ou réutilise celui d'un autre projet, le broker peut le refuser même si le mot de passe est correct.
Vérifiez que la bibliothèque envoie les identifiants. Dans Paho, username_pw_set() doit être appelé avant connect(). Dans PubSubClient pour Arduino, utilisez la surcharge connect(clientId, user, pass), pas connect(clientId).
Vérifiez les guillemets du shell. Les mots de passe contenant $, ! ou & sont altérés par Bash. Utilisez des apostrophes simples : -P 'p@ss$word!'.
Vérifiez le port et le transport. Le port 1883 est en TCP simple, 8883 en TLS, 8083 en WebSocket et 8084 en WebSocket sécurisé avec le chemin /mqtt. Une erreur de port produit généralement un timeout ou une erreur TLS plutôt que « not authorized », mais un client mal configuré peut finir par parler à un autre listener ou à un autre environnement que prévu.
Confirmez que le compte est actif. Les identifiants ont peut-être été régénérés, un broker supprimé ou recréé, ou vous utilisez peut-être des identifiants de préproduction contre la production.
Vérifiez les quotas de connexions. Si la limite de connexions de l'offre est atteinte, les clients MQTT 5 reçoivent 0x97 Quota exceeded, mais certaines bibliothèques 3.1.1 remontent tout refus de manière générique. Comptez vos connexions actives.
Arrêtez de réessayer en boucle. Chaque tentative échouée est, du point de vue du broker, un échec de connexion. Espacez les tentatives pendant votre enquête.

Tester les identifiants en ligne de commande

Isolez votre application du problème en testant exactement les mêmes identifiants avec les outils Mosquitto. Commencez par prouver que le chemin réseau fonctionne avec le serveur MQTT public gratuit, anonyme et réservé aux tests :

mosquitto_sub -h broker.connectmq.com -p 1883 -i auth-check-2d9f \
  -t "connectmq/demo/2d9f/#" -d -C 1 -W 5

Si vous voyez received CONNACK (0), votre machine peut joindre le broker et parler MQTT. Testez ensuite vos identifiants privés en TLS :

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u 'YOUR_USERNAME' -P 'YOUR_PASSWORD' -i 'YOUR_CLIENT_ID' \
  -t "test/#" -d -V mqttv5

Avec -V mqttv5, un refus affiche le reason code MQTT 5, plus précis que le code 3.1.1. Si cette commande se connecte mais pas votre application, le problème vient de la configuration de l'application, pas du compte. Si cette commande échoue aussi, le problème vient des identifiants, du client ID ou du compte.

Sous Windows, --capath n'est pas disponible sous la même forme ; utilisez plutôt --cafile avec un fichier de bundle CA, ou testez avec un client MQTT graphique.

Corriger le problème dans le code

Voici un client Python qui affiche la configuration qu'il utilise réellement et s'arrête sur les erreurs d'autorisation au lieu de réessayer indéfiniment :

import os
import ssl
import paho.mqtt.client as mqtt

HOST = os.getenv("MQTT_HOST", "broker.connectmq.com")
PORT = int(os.getenv("MQTT_PORT", "8883"))
USERNAME = os.getenv("MQTT_USERNAME", "YOUR_USERNAME")
PASSWORD = os.getenv("MQTT_PASSWORD", "YOUR_PASSWORD")
CLIENT_ID = os.getenv("MQTT_CLIENT_ID", "YOUR_CLIENT_ID")

print(f"Connecting to {HOST}:{PORT} as user={USERNAME!r} client_id={CLIENT_ID!r}")

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print(f"Refused: {reason_code} (0x{reason_code.value:02X})")
        if reason_code.value in (0x85, 0x86, 0x87):
            print("Identity problem: check username, password and client ID")
            client.disconnect()
        return
    print("Connected")

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=CLIENT_ID,
    protocol=mqtt.MQTTv5,
)
client.username_pw_set(USERNAME, PASSWORD)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.connect(HOST, PORT, keepalive=60)
client.loop_forever()

Le formatage !r affiche les valeurs entre guillemets, ce qui rend évidents les espaces invisibles. Cette seule ligne a résolu bien des enquêtes du type « mon mot de passe est forcément bon ».

Sur un ESP32 avec PubSubClient, l'erreur courante concerne la surcharge :

// Faux : aucun identifiant n'est envoyé
mqtt.connect("YOUR_CLIENT_ID");

// Correct : client ID, nom d'utilisateur et mot de passe
mqtt.connect("YOUR_CLIENT_ID", "YOUR_USERNAME", "YOUR_PASSWORD");

« Not Authorized » après la connexion

Il arrive que la connexion réussisse mais que des opérations ultérieures échouent avec « not authorized ». En MQTT 5, vous verrez 0x87 dans un SUBACK, un PUBACK ou un DISCONNECT. Cela signifie que le client peut se connecter mais n'a pas le droit d'utiliser un topic précis, par exemple un préfixe réservé. En MQTT 3.1.1, il n'existe pas de reason code pour une publication rejetée : le message peut donc simplement disparaître. Si des messages se volatilisent, connectez-vous temporairement en MQTT 5 pour voir le reason code réel. La référence des reason codes MQTT répertorie chaque code par type de paquet.

Comment cela fonctionne sur ConnectMQ

Sur ConnectMQ, chaque broker que vous créez dans le portail reçoit un nom d'utilisateur, un mot de passe et un client ID générés, et le client ID est lié à ces identifiants. C'est la première chose à vérifier quand vous voyez 0x87 : utilisez-vous les trois valeurs du même broker ? Les brokers sont isolés par tenant : les identifiants d'un broker ne fonctionnent donc pas sur un autre, même au sein du même compte.

Deux autres comportements de la plateforme sont bons à connaître :

Les échecs de connexion sont limités. Après des échecs répétés, l'adresse IP source est bloquée. Un appareil coincé dans une boucle de reconnexion serrée avec des identifiants périmés peut bloquer les autres appareils situés derrière le même NAT. Utilisez un backoff exponentiel.
Les limites de connexions dépendent de l'offre. L'offre Serverless gratuite autorise jusqu'à 25 connexions simultanées. Les dépasser produit 0x97 Quota exceeded pour les clients MQTT 5, et non « not authorized », ce qui est une raison de préférer MQTT 5 pendant le débogage.

Pour un durcissement allant au-delà de l'authentification, consultez les bonnes pratiques de sécurité MQTT, et le tutoriel MQTT pour une vue d'ensemble du protocole.

Se connecter en toute sécurité avec ConnectMQ

Un broker MQTT managé qui émet des identifiants et des client ID cohérents élimine la plupart des causes de cette erreur avant qu'elles ne surviennent. Inscrivez-vous sur app.connectmq.com pour obtenir un broker Serverless gratuit sans carte bancaire, et utilisez le client MQTT intégré au navigateur pour vérifier que vos identifiants fonctionnent avant de flasher le moindre appareil. Découvrez aussi comment exploiter un broker MQTT cloud.

Questions fréquentes

Que signifie « Connection Refused: not authorised » dans les outils Mosquitto ?

C'est le code de retour CONNACK 5. Le broker a reçu un CONNECT valide mais a refusé le client, généralement à cause d'identifiants erronés, d'un client ID non lié au compte ou d'identifiants appartenant à un autre broker.

« Not authorized » est-il identique à « bad username or password » ?

Pas exactement. Bad username or password correspond au code 4 (0x86) et signifie que les identifiants ne correspondent pas ; not authorized correspond au code 5 (0x87) et couvre des problèmes de permissions plus larges. Certains brokers utilisent le code 5 dans les deux cas : vérifiez donc d'abord les identifiants dans tous les cas.

Pourquoi mon client se connecte-t-il avec mosquitto_sub mais pas depuis mon application ?

L'application envoie quelque chose de différent : un autre hôte, un client ID généré, des identifiants manquants ou un mot de passe altéré. Affichez la configuration effective à l'exécution et comparez-la avec la commande qui fonctionne.

Des échecs de connexion répétés peuvent-ils poser problème ?

Oui. Beaucoup de brokers, dont ConnectMQ, bloquent les adresses IP après des échecs de connexion répétés. Utilisez un backoff exponentiel et cessez de réessayer sur les erreurs d'autorisation.

Corriger « MQTT Connection Refused: Not Authorized » (rc 5 et 0x87)