📚 课程目录第4章身份认证基础

4、身份认证基础：客户端标识符、用户名密码认证、认证流程与常见问题

4.1 核心原理：MQTT 身份认证的三要素

MQTT 协议本身并不强制要求复杂的认证机制，它默认信任网络层。但在实际物联网部署中，我们必须显式地建立身份认证体系。MQTT 身份认证的核心由三个要素构成：客户端标识符（Client ID）、用户名（Username）与密码（Password）。这三者共同决定了 Broker（代理服务器）如何识别并信任一个连接请求。

关键理解：Client ID 是设备的“身份证号”，Username 是“账户名”，Password 是“账户密钥”。Broker 首先通过 Client ID 判断这是“谁”在连接（用于会话续接），再通过 Username/Password 验证“你是否真的是你声称的那个人”。

Client ID 在 MQTT 3.1.1 中为必填项，且在同一个 Broker 上必须唯一。如果两个客户端使用相同的 Client ID 连接，Broker 会强制断开前一个连接（即“踢下线”机制）。Username 和 Password 则承载在 CONNECT 报文的可变头部（Variable Header）和载荷（Payload）中，以 UTF-8 编码字符串形式传输。

4.2 认证流程与报文结构

一次完整的 MQTT 身份认证发生在 TCP 连接建立之后、任何 PUBLISH/SUBSCRIBE 之前。其流程严格遵循“请求-应答”模式，具体步骤如下：

建立 TCP 连接：客户端与 Broker 完成底层 TCP 三次握手（若使用 TLS，则在此阶段完成 TLS 握手）。
发送 CONNECT 报文：客户端将 Client ID、Username、Password 填入 CONNECT 报文的对应字段。
Broker 校验：Broker 依次检查 Client ID 合法性、Username 是否存在、Password 是否匹配。
返回 CONNACK 报文：Broker 返回连接确认报文，其中包含返回码（Return Code）。

CONNECT 报文的关键结构如下（以 MQTT 3.1.1 为例）：

CONNECT 报文结构:
  - 固定头部: 0x10 (CONNECT 类型)
  - 剩余长度: 可变
  - 协议名: "MQTT" (0x00 0x04 M Q T T)
  - 协议级别: 0x04 (3.1.1)
  - 连接标志: [Username Flag] [Password Flag] [Will Flag] ...
  - 保持连接: 60 秒 (示例)
  - 载荷:
      Client ID: "device-001"
      Username: "sensor-user"
      Password: "secret123"

CONNACK 报文中的返回码是认证结果的直接体现。下表列出了常见的返回码及其含义：

返回码	含义	常见触发场景
0x00	连接已接受	认证通过，正常建立会话
0x02	标识符不正确	Client ID 包含非法字符或长度超限
0x04	连接被拒绝	用户名或密码错误
0x05	未授权连接	用户存在但无权限访问该 Broker

4.3 典型场景与配置示例

以 EMQX 和 Mosquitto 两个主流 Broker 为例，展示如何配置用户名密码认证。

场景一：Mosquitto 静态密码认证

Mosquitto 使用 password_file 存放用户名和密码哈希。首先使用 mosquitto_passwd 工具创建密码文件：

# 创建密码文件并添加用户
mosquitto_passwd -c /etc/mosquitto/passwd sensor-user
# 输出提示输入密码，输入 "secret123"

# 在 mosquitto.conf 中启用认证
echo "allow_anonymous false" >> /etc/mosquitto/mosquitto.conf
echo "password_file /etc/mosquitto/passwd" >> /etc/mosquitto/mosquitto.conf

# 重启服务
systemctl restart mosquitto

场景二：EMQX 内置数据库认证

EMQX 提供了更灵活的认证管理方式，可通过 Dashboard 或 API 添加用户：

# 使用 EMQX API 创建用户
curl -X POST http://localhost:8081/api/v5/authentication/password_based:built_in_database/users \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "device-001",
    "password": "secret123",
    "is_superuser": false
  }'

# 客户端连接时需携带
# Client ID: device-001
# Username: device-001
# Password: secret123

最佳实践：生产环境中，密码不应以明文存储或传输。建议使用 TLS 加密传输层，并在 Broker 端配置密码哈希存储（如 bcrypt、PBKDF2）。同时，为每个设备分配独立的 Username/Password，避免共用账户。

4.4 常见误区与故障复盘

在实际项目中，身份认证环节经常出现以下几类问题，导致设备无法连接或产生安全隐患。

误区一：Client ID 重复导致互踢

某工厂部署了 50 台温湿度传感器，但固件中写死了相同的 Client ID "temp-sensor"。当第二台设备上线时，Broker 立即断开第一台设备的连接，导致设备反复掉线重连。排查时发现 Broker 日志中频繁出现 client temp-sensor already connected 的警告。

解决方案：将设备 MAC 地址或序列号后六位拼接到 Client ID 中，确保全局唯一。

误区二：Username 与 Client ID 混淆

很多开发者误以为 Username 就是 Client ID，或者两者必须相同。实际上，Client ID 用于会话管理，Username 用于权限识别。在 EMQX 中，可以通过 ACL（访问控制列表）针对 Username 设置主题权限，而 Client ID 不具备该能力。例如，可以允许 user-a 发布到 sensors/user-a/#，但禁止其订阅其他用户的主题。

误区三：忽略密码安全传输

在未启用 TLS 的 MQTT 连接中，Username 和 Password 以 Base64 编码（非加密）传输，攻击者抓包即可还原明文。某智能家居项目曾因使用 1883 端口明文传输，导致用户密码泄露。正确的做法是：

使用 8883 端口（TLS 加密）或 8084 端口（WebSocket + TLS）
在 Broker 端强制要求 TLS，拒绝非加密连接
定期轮换密码，避免长期使用同一密钥

误区四：CONNACK 返回码 0x04 与 0x05 的区分

返回码 0x04 表示“用户名或密码错误”，而 0x05 表示“未授权”。前者是认证失败（credentials invalid），后者是授权失败（not authorized）。例如，用户存在且密码正确，但该用户被禁止连接此 Broker 时，返回 0x05。排查问题时，应结合 Broker 日志区分这两类错误，避免盲目重置密码。

复盘案例：某车联网平台在设备接入时频繁报错 0x04。工程师检查发现，设备端代码中密码字段拼接了多余的空格字符，导致哈希比对失败。通过打印 CONNECT 报文十六进制数据，定位到密码尾部多出 0x20（空格），修复后连接恢复正常。这提醒我们：认证字段对字符精确性极其敏感，任何不可见字符差异都会导致认证失败。

综上所述，MQTT 身份认证虽然概念简单，但在工程落地中需要细致处理 Client ID 唯一性、密码安全存储与传输、以及错误码的准确解读。建议在开发阶段就建立完整的认证测试用例，覆盖正常连接、错误密码、重复 Client ID、非法字符等场景，确保设备接入的健壮性。