4. 设备身份认证协议：双向TLS、OAuth2.0设备授权流与挑战-响应机制

设备身份认证，说白了就是回答一个问题：「你怎么证明你是你？」

在IoT场景里，这个问题比Web场景难得多。设备没有浏览器，没有用户输入密码，甚至可能离线。我这些年做过的项目里，因为认证协议选型翻车的案例，一只手数不过来。

今天咱们就聊三种主流方案：双向TLS、OAuth2.0设备授权流、挑战-响应机制。每种都有它的适用场景，也有它的坑。

4.1 双向TLS（mTLS）

单向TLS大家都很熟——客户端验证服务器证书。双向TLS呢？服务器也要验证客户端的证书。说白了，就是双方都亮出身份证。

4.1.1 握手流程

1. 客户端发起ClientHello
2. 服务端返回ServerHello + 服务端证书 + 请求客户端证书（CertificateRequest）
3. 客户端验证服务端证书，然后发送自己的客户端证书
4. 服务端验证客户端证书的签名链和有效期
5. 双方完成密钥协商，建立安全通道

嗯，这里要注意：客户端证书的私钥必须安全存储。我在一个智能门锁项目里遇到过，厂商把私钥直接写死在固件里，结果被逆向出来，整个批次的门锁都能被远程开锁。那叫一个惨。

4.1.2 适用场景

场景	推荐度	说明
网关设备	★★★★★	计算资源充足，证书管理成熟
传感器节点	★★★☆☆	资源受限，需考虑证书存储开销
移动设备	★★☆☆☆	证书更新困难，更适合OAuth2.0

4.2 OAuth2.0设备授权流

你想想看，智能电视、打印机这种设备，没有键盘，怎么让用户授权它访问云服务？OAuth2.0设备授权流（Device Authorization Grant）就是干这个的。

我个人习惯叫它「扫码流」——用户在一个设备上看到授权码，然后在另一个设备（比如手机）上完成授权。

4.2.1 流程拆解

1. 设备向授权服务器请求设备码和用户码
2. 设备显示用户码（比如一串数字或二维码）
3. 用户在手机/电脑上访问授权页面，输入用户码
4. 用户完成身份验证并授权
5. 设备轮询授权服务器，获取访问令牌

// 设备请求设备码
POST /device/code HTTP/1.1
Content-Type: application/x-www-form-urlencoded

client_id=smart_tv_001&scope=read_write

// 响应
{
  "device_code": "dGhpcyBpcyBhIHNhbXBsZQ",
  "user_code": "ABCD-1234",
  "verification_uri": "https://example.com/device",
  "expires_in": 1800,
  "interval": 5
}

4.2.2 安全要点

• 用户码必须足够随机：至少8位字符，防止暴力猜测
• 设备码必须绑定客户端ID：防止A设备的码被B设备冒领
• 令牌传输必须走TLS：这个不用多说吧？

4.3 挑战-响应机制

这个机制其实很古老，但在IoT里依然好用。它的核心思想是：服务器给设备出一道题，设备答对了就证明身份。

说白了，就是「你证明你知道一个秘密，但不用把秘密说出来」。

4.3.1 经典流程

1. 设备发起认证请求
2. 服务器生成一个随机数（Nonce），作为挑战
3. 设备用预共享密钥对Nonce进行签名或加密
4. 服务器验证响应，确认设备持有正确密钥

// 服务器下发挑战
{
  "challenge": "a1b2c3d4e5f6",
  "algorithm": "HMAC-SHA256"
}

// 设备响应
{
  "device_id": "sensor_001",
  "response": "6f8a7b9c...",
  "timestamp": 1700000000
}

4.3.2 三种方案对比

维度	双向TLS	OAuth2.0设备流	挑战-响应
计算开销	高（证书验证）	中（HTTP请求）	低（对称运算）
密钥管理	复杂（CA体系）	中等（令牌管理）	简单（预共享密钥）
离线支持	不支持	不支持	支持（本地验证）
抗重放	强（TLS层）	强（Nonce+时间戳）	需额外实现

4.4 核心逻辑关系图

下面这张图展示了三种协议在设备身份生命周期中的位置和关系：

4.5 我的选型建议

做了这么多年IoT安全，我总结了一个简单的判断逻辑：

• 设备能跑TLS握手吗？能 → 优先mTLS。不能 → 看下一条。
• 设备有人机交互吗？有（屏幕、按键）→ OAuth2.0设备流。没有 → 挑战-响应。
• 设备需要离线工作吗？需要 → 挑战-响应。不需要 → 看资源情况。