概述
消息队列 MQTT 版提供了多种认证方式以保证服务端与客户端之间通信的安全性，客户端接入时，将按照配置的认证方式对客户端的身份进行验证，通过认证后才被允许接入，确保设备的合法接入。
MQTT 的安全机制由两层组成，两层独立工作、可叠加生效：
传输层：是 MQTT 协议体系的底层通信基础，它负责在 MQTT 客户端与服务端之间建立安全通信通道，包括 TLS 加密、服务端证书校验等。该层并非 MQTT 协议本身的一部分，而是依赖于现有的网络传输协议来实现其功能。
应用层：是 MQTT 应用协议中的一个核心安全组件，作用于连接建立阶段。它负责对尝试连接到服务端的客户端身份进行验证，确保只有经过授权的客户端才能接入服务并访问系统资源。
层级 | 作用阶段 | 能做什么 | 涉及的认证方式 |
传输层（TLS 层） | TCP 连接建立时的 TLS 握手阶段 | 加密通道 + 基于 X.509 证书的握手校验 | 单向认证（TLS）、双向认证（mTLS）、一机一证（握手部分） |
应用层（MQTT 协议层） | TLS 握手完成之后、发送 CONNECT 报文时 | 基于凭证/令牌的业务身份验证 | 用户名+密码、JWT 认证、外部 HTTP 认证、一机一密、一机一证（身份判定） |
注意：
传输层和应用层是
AND 关系。如果同时启用了“双向认证（mTLS）”和“用户名 + 密码”，客户端必须同时通过两层验证才能接入。X.509 证书认证
X.509 是一种标准的公钥证书格式，广泛用于互联网的安全通信中。消息队列 MQTT 版支持基于 X.509 证书建立传输层加密连接与认证能力，以实现更高级别的通信安全保障。消息队列 MQTT 版当前支持以下 X.509 证书认证方式：
一机一证
说明：
TLS/mTLS 本身不是一种客户端业务身份认证方式，客户端的身份验证仍需通过应用层的用户名+密码 / JWT / HTTP 等应用层认证完成。
X.509 证书相关的三种认证配置：单向认证（TLS）、双向认证（mTLS）、一机一证互斥，在同一时刻只能选择其中一种。
一机一证在传输层和应用层都有逻辑：TLS 握手做证书校验、应用层认证器链中把证书直接转换为业务身份，启用一机一证后，后续应用层认证器不会再执行，即其他应用层认证方式不会生效。
应用层认证
应用层的认证方式基于认证器链（Authenticator Chain）模型，默认所有支持的认证器可以共存。消息队列 MQTT 版当前支持以下认证方式：
JWT 认证
HTTP 认证
一机一密
认证器链工作机制
客户端发送 CONNECT 报文后，MQTT 集群按顺序逐个调用已启用的认证器，每个认证器只会返回三种结果之一：
认证器返回 | 含义 | 链路行为 |
NOT_FOUND | 客户端没有提供该认证器所需的凭证（例如未提供 JWT） | 继续走下一个认证器 |
ALLOW | 凭证校验通过 | 立即放行，后续认证器不再执行 |
DENY / QUOTA_EXCEEDED | 凭证校验拒绝（密码错误、配额超限等） | 立即拒绝，后续认证器不再执行 |
流程示意图：
判定规则：
短路通过：任一认证器返回
ALLOW，立即放行，后续认证器不再执行。跳过继续：认证器返回
NOT_FOUND（客户端未携带其所需凭证），链条继续走下一个。短路拒绝：任一认证器返回
DENY 或 QUOTA_EXCEEDED（凭证错误或超限），立即拒绝，后续不再执行。全部跳过：所有已启用认证器都返回
NOT_FOUND（客户端没有提交任何可识别凭证），最终也按 DENY 处理，拒绝接入。适用场景
认证方式 | 说明 | 基础版 （已售罄） | 专业版 | 铂金版 | 适用场景 |
用户名+密码认证 | 最基础的认证方式，客户端在连接时提供用户名（Username）和密码（Password），MQTT 将其与内部存储的凭证进行匹配，匹配通过后接受客户端请求。 | ✓ | ✓ | ✓ | 通用场景，安全性要求不高。 |
X.509 证书认证 | 单向认证（TLS）：由客户端认证服务端，客户端对服务端的认证通过服务端证书完成。服务端会使用您选择的证书和客户端建联。 | ✓ | ✓ | ✓ | 对安全性要求一般，或者测试场景。 |
| 双向认证（mTLS）：客户端与服务端之间相互认证，客户端对服务端的认证通过服务端证书完成，服务端对客户端的认证通过 CA 证书完成。验证通过则允许客户端连接服务端。 | ✓ | ✓ | ✓ | 设备价值较高，对安全性要求较高。 |
| 一机一证：一种特殊的双向认证，每个客户端（每台设备）使用自行签发的 CA 证书及 CA 证书签发的不同的客户端证书（设备证书）进行认证。 | × | ✓ | ✓ | 设备价值极高，对安全性要求极高。 |
JWT 认证 | JWT 认证是基于 Token 的鉴权机制，不依赖服务端保留客户端的认证信息或者会话信息，客户端在密码字段或单独字段中提交 JWT，MQTT 将验证 JWT 的签名和声明信息，验证通过后服务端接受客户端连接请求。 | × | ✓ | ✓ | 面向终端用户或临时会话，实现灵活的、带有时效性和自定义权限的动态鉴权。 |
HTTP 认证 | 客户端连接时，MQTT 将使用客户端信息构造 HTTP 请求，并根据请求返回的内容判断认证结果，认证通过，则允许该客户端连接服务端。 | × | ✓ | ✓ | 需要与企业现有统一身份认证体系集成的鉴权场景。 |
一机一密 | 每台设备使用独立的密钥，用于连接服务端进行认证。这个密钥是设备身份的唯一证明，用于连接服务端时的认证。 | × | ✓ | ✓ | 对安全有较高的诉求， 但是设备本身的算力比较有限， 无法支持使用基于 PKI 证书的“一机一证”。 |
选型建议
业务诉求 | 推荐组合 | 说明 |
通用业务，只需加密 + 简单身份识别 | 单向认证（TLS） + 用户名密码 | 最常见入门组合 |
需要时效性权限、面向终端用户 | 单向认证（TLS） + JWT（可叠加用户名密码作为兜底） | 利用 JWT 控制细粒度权限 |
已有企业统一身份系统 | 单向认证（TLS） + HTTP 外部认证 | 把身份判定下沉到外部服务 |
中高安全要求、设备有证书能力 | 双向认证（mTLS） + 用户名密码 / JWT | mTLS 做传输层互验，应用层确定业务身份 |
极高安全要求、车联网/高价值设备 | 一机一证 | 证书直接 = 身份，开箱即用 |
高安全要求、但设备算力有限 | 单向认证（TLS）/ 双向认证（mTLS）+ 一机一密 | mTLS/TLS 提供传输层安全，一机一密在应用层确定每台设备的业务身份，两者分属不同层级。 |
常见问题
Q1：可以同时开启“用户名 + 密码”和“JWT”吗？
可以。两者都是应用层认证器，默认共存。如果客户端同时提交两类凭证，会按照认证器链的顺序执行。
Q2：“一机一密”和“一机一证”可以同时启用吗？
技术上可以同时启用，但二者属于不同的认证哲学（对称密钥 vs PKI 证书），同一台设备不建议两种都用。一般做法是整批设备二选一。
Q3：启用一机一证后，HTTP 外部认证、用户名密码还会被调用吗？
实际上不会。原因不是“应用层认证链被关闭”，而是开启一机一证后：
在 TLS 握手阶段，会强制要求客户端出示一张由用户 CA 签发的有效证书，无证书或证书无效的客户端在 TCP 层就被断开，根本走不到 CONNECT。
通过 TLS 握手后，客户端的证书会被一机一证认证器直接判定为 ALLOW，链路短路，后续的认证器不会再被调用。
因此从效果看，“启用一机一证 = 应用层只剩一机一证生效”，但底层机制是 TLS 握手拦截 + 链路短路，不是配置层面的互斥。
