在物联网场景中，设备与平台的通信安全是核心基石。MQTT作为应用最广泛的物联网协议，其认证机制的设计直接决定了系统抗攻击能力。本文结合多个工程案例，从「用户名密码的安全隐患」入手，逐步深入TLS双向认证、OAuth2.0集成、Token动态刷新及证书吊销机制，提供可落地的安全方案与经验教训。

一、用户名密码认证：看似便捷的安全陷阱

用户名密码认证是MQTT最基础的认证方式，通过CONNECT报文的Username和Password字段实现。但在实际工程中，这种方式存在致命风险，我们先从一个真实案例说起。

案例：智慧园区设备被恶意控制

某智慧园区部署了5000台智能门禁，采用「用户名+静态密码」认证（密码硬编码在设备固件中）。攻击者通过逆向工程获取固件中的密码后，伪装成合法设备接入MQTT平台，发送开门指令，导致非授权人员进入园区。

安全风险深度剖析

1. 明文传输隐患
   MQTT协议本身不加密Username/Password，若未启用TLS，密码会以明文在网络中传输，可被中间人直接捕获。即使启用TLS，密码泄露的风险依然存在（如固件逆向、日志泄露）。

2. 静态密码难以更新
   设备部署后，静态密码的更新需要固件升级或远程配置，对于百万级设备集群几乎不可行。某水务项目中，因密码泄露需更新10万台水表密码，导致30%设备离线（升级失败）。

3. 缺乏细粒度权限控制
   用户名密码仅能验证「身份合法性」，无法控制设备的操作范围（如禁止某设备订阅控制指令主题）。攻击者获取密码后可执行任意操作。

适用场景

仅推荐用于「测试环境」或「无安全需求的内部系统」。生产环境中，需搭配其他认证机制（如TLS）作为过渡方案。

二、TLS双向认证：设备与平台的「双向身份核验」

TLS双向认证（又称「证书认证」）是工业级物联网的首选方案，通过「客户端证书+服务端证书」实现双向身份验证。其核心逻辑是：设备验证平台合法性，平台同时验证设备合法性，从根本上杜绝伪装攻击。

案例：电力系统的双向认证实践

某省级电力公司部署了2万台配电终端，要求「设备与平台通信必须经过身份双向核验」。采用TLS双向认证后，成功拦截37次伪造设备的接入尝试（攻击者持有平台证书，但无合法客户端证书）。

配置步骤（基于EMQX与OpenSSL）

1. 生成证书链（CA+服务端证书+客户端证书）

使用OpenSSL构建私有证书体系（生产环境建议使用公信力CA，如Let’s Encrypt）：

# 1. 生成根CA私钥与证书（有效期10年）  
openssl genrsa -out ca.key 2048  
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -subj "/CN=IoT-CA"  

# 2. 生成服务端证书（用于MQTT Broker）  
openssl genrsa -out server.key 2048  
openssl req -new -key server.key -out server.csr -subj "/CN=mqtt.broker.com"  
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365  

# 3. 生成客户端证书（每台设备一个证书，CN设为设备唯一标识）  
openssl genrsa -out device_001.key 2048  
openssl req -new -key device_001.key -out device_001.csr -subj "/CN=device_001"  
openssl x509 -req -in device_001.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out device_001.crt -days 365  

2. 服务端配置（EMQX为例）

在emqx.conf中启用TLS监听，指定服务端证书与CA证书：

# 启用8883端口（MQTT over TLS）  
listener.ssl.external = 8883  

# 服务端证书与私钥  
listener.ssl.external.certfile = /etc/emqx/certs/server.crt  
listener.ssl.external.keyfile = /etc/emqx/certs/server.key  

# 信任的根CA（用于验证客户端证书）  
listener.ssl.external.cacertfile = /etc/emqx/certs/ca.crt  

# 开启双向认证（强制验证客户端证书）  
listener.ssl.external.verify = verify_peer  
listener.ssl.external.fail_if_no_peer_cert = true  

3. 客户端配置（以Python为例）

客户端需携带自身证书与私钥，连接时验证服务端证书：

import ssl  
import paho.mqtt.client as mqtt  

# 加载客户端证书、私钥与根CA  
ssl_context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)  
ssl_context.load_cert_chain(certfile="device_001.crt", keyfile="device_001.key")  
ssl_context.load_verify_locations(cafile="ca.crt")  # 验证服务端证书  
ssl_context.verify_mode = ssl.CERT_REQUIRED  # 强制验证服务端身份  

# 连接MQTT Broker（TLS双向认证）  
client = mqtt.Client(client_id="device_001")  
client.tls_set_context(ssl_context)  
client.connect("mqtt.broker.com", port=8883)  
client.loop_forever()  

优势与注意事项

• 优势：安全性极高，证书难以伪造；支持基于证书CN字段的细粒度权限控制（如CN=device_001仅允许订阅device/001/#）。
• 注意事项：证书管理成本高（需为每台设备生成证书）；证书过期前需提前更新（某项目因100台设备证书过期导致离线）。

三、OAuth2.0集成：多系统协同的认证方案

当物联网平台需要与第三方系统（如用户管理平台、OA系统）集成时，OAuth2.0是最佳选择。其核心是通过「令牌（Token）」替代密码，实现跨系统授权。

案例：智能家居平台的第三方授权

某智能家居平台需要对接多个设备厂商的系统，采用OAuth2.0授权：

1. 设备厂商的系统通过OAuth2.0向平台申请「设备管理Token」；
2. 厂商设备使用该Token接入MQTT平台，平台验证Token合法性后允许接入；
3. Token权限被限制（如仅允许发布设备状态，禁止订阅控制指令）。

集成方案（EMQX+Keycloak）

1. 架构设计

• 认证流程：设备→MQTT Broker→OAuth2.0服务器（验证Token）→返回权限。
• 组件角色：
  • Keycloak：OAuth2.0授权服务器，负责Token生成与验证；
  • EMQX：MQTT Broker，通过插件调用Keycloak接口验证Token。

2. 配置步骤

（1）Keycloak配置

• 创建「客户端」（代表MQTT平台），设置Access Type=confidential；
• 创建「角色」（如device_publish允许发布，device_subscribe允许订阅）；
• 配置Token有效期（如访问令牌2小时，刷新令牌7天）。

（2）EMQX配置

启用emqx_auth_oauth2插件，配置Keycloak验证接口：

# 启用OAuth2.0认证插件  
auth.oauth2 = on  

# Keycloak的Token验证接口  
auth.oauth2.url = "http://keycloak:8080/auth/realms/iot/protocol/openid-connect/userinfo"  

# 从Token中提取设备标识（如sub字段）  
auth.oauth2.username_claim = sub  

# 从Token的"roles"字段提取权限  
auth.oauth2.scope_claim = roles  
auth.oauth2.scope_delimiter = ","  

# 权限映射（Token角色→MQTT操作）  
auth.oauth2.acl_rules = {  
  "device_publish": { "publish": ["device/${username}/status"] },  
  "device_subscribe": { "subscribe": ["device/${username}/cmd"] }  
}  

（3）客户端接入

设备通过OAuth2.0流程获取Token后，将Token作为密码接入MQTT：

client = mqtt.Client(client_id="device_001")  
client.username_pw_set(username="device_001", password="ACCESS_TOKEN")  # Token作为密码  
client.connect("mqtt.broker.com", port=1883)  # 需搭配TLS加密Token  

适用场景

多系统集成、第三方设备接入、需要临时授权的场景（如临时开放某设备的调试权限）。

四、Token认证动态刷新：避免频繁断连的关键

Token存在有效期，若过期后重新认证，会导致设备断连。动态刷新机制通过「刷新令牌」在Token过期前自动更新，保证连接持续性。

案例：车联网的Token刷新实践

某车厂的10万辆车通过Token认证接入平台，Token有效期2小时。采用动态刷新后，设备断连率从15%（Token过期）降至0.3%。

实现方案

1. 客户端逻辑

• 存储「访问令牌」（短期有效，如2小时）和「刷新令牌」（长期有效，如7天）；
• 当访问令牌剩余有效期＜30分钟时，用刷新令牌请求新访问令牌；
• 新Token获取后，通过CONNACK报文的User Property更新Broker缓存。

def refresh_token():  
    # 调用OAuth2.0刷新接口  
    response = requests.post(  
        "http://keycloak:8080/auth/realms/iot/protocol/openid-connect/token",  
        data={  
            "grant_type": "refresh_token",  
            "refresh_token": REFRESH_TOKEN,  
            "client_id": "mqtt-client"  
        }  
    )  
    new_tokens = response.json()  
    return new_tokens["access_token"], new_tokens["refresh_token"]  

# 定时检查Token有效期，提前刷新  
def check_token_expiry():  
    if time.time() > (TOKEN_EXPIRY - 300):  # 提前5分钟刷新  
        global ACCESS_TOKEN, REFRESH_TOKEN  
        ACCESS_TOKEN, REFRESH_TOKEN = refresh_token()  
        # 发送空消息触发Broker更新Token缓存（通过User Property传递新Token）  
        client.publish(  
            topic="$token/refresh",  
            payload="",  
            properties={"UserProperty": [("new_token", ACCESS_TOKEN)]}  
        )  

2. 服务端逻辑

• Broker缓存Token与设备的映射关系；
• 收到客户端的Token刷新请求后，更新缓存中的Token；
• 若刷新令牌过期，强制设备重新认证。

五、客户端证书吊销：设备失陷后的止损机制

当设备丢失、证书泄露或设备退役时，需立即吊销其证书，禁止接入。若缺乏吊销机制，攻击者可利用被盗证书长期接入系统。

案例：物流追踪器的证书吊销

某物流公司的100台追踪器被盗，因未启用证书吊销机制，攻击者持续使用被盗证书接入平台，伪造位置信息导致调度混乱。

实践方案

1. CRL（证书吊销列表）机制

• 原理：CA定期发布包含吊销证书序列号的列表（CRL），Broker定期下载并校验客户端证书是否在列表中。

• 配置步骤：
  （1）生成CRL并吊销设备证书：

  # 吊销device_001证书（需CA私钥）  
  openssl ca -revoke device_001.crt -keyfile ca.key -cert ca.crt  
  # 生成CRL（有效期7天）  
  openssl ca -gencrl -out crl.pem -keyfile ca.key -cert ca.crt -crldays 7  
  

  （2）EMQX配置CRL检查：

  # 启用CRL检查  
  listener.ssl.external.crlfile = /etc/emqx/certs/crl.pem  
  

2. OCSP（在线证书状态协议）机制

• 原理：Broker在客户端连接时，实时向OCSP服务器查询证书状态（是否吊销），适合对实时性要求高的场景。
• 配置步骤：
  （1）搭建OCSP服务器（如使用OpenSSL的ocspd）；
  （2）EMQX配置OCSP检查：

  listener.ssl.external.ocsp_url = "http://ocsp.server.com:8080"  # OCSP服务器地址  
  listener.ssl.external.ocsp_enable = true  
  

经验教训

• CRL机制存在「时间差风险」（CRL更新周期内，吊销证书仍可接入），建议周期≤1小时；
• OCSP依赖实时网络请求，需配置超时重试（某项目因OCSP服务器宕机导致所有设备无法接入）；
• 证书吊销后，需强制已连接设备断开（通过emqx_ctl clients kick命令）。

六、总结：物联网认证机制的选择策略

认证方式	安全性	易用性	适用场景	核心教训
用户名密码	低	高	测试环境、内部系统	禁止明文传输，必须搭配TLS
TLS双向认证	极高	中	工业控制、金融物联网	证书需定期更新，做好生命周期管理
OAuth2.0集成	高	中	多系统协同、第三方接入	Token必须通过TLS传输
Token动态刷新	高	高	移动设备、长期在线场景	刷新令牌需加密存储
证书吊销（CRL/OCSP）	极高	低	设备防盗、证书泄露场景	优先用OCSP+CRL混合方案

物联网安全没有「银弹」，需根据业务场景组合认证机制（如「TLS双向认证+证书吊销」用于工业控制，「OAuth2.0+Token刷新」用于第三方设备接入）。同时，定期进行安全审计（如检查弱证书、过期Token），才能构建真正可靠的物联网安全体系。