.webp){kind=small}
Token 如何绑定设备：防止泄漏后跨设备使用
Token 如何绑定设备：防止泄漏后跨设备使用
普通 Bearer Token 的规则很简单：谁拿到 Token，谁就能调用接口。
因此，Token 一旦被日志、代理、恶意软件或客户端漏洞窃取，攻击者通常可以把它复制到另一台设备继续使用。解决这类问题的技术一般叫：
设备绑定：Device Binding
发送方约束 Token：Sender-Constrained Token
持有证明 Token：Proof-of-Possession Token，简称 PoP Token
核心目标不是保证 Token 永不泄漏，而是让攻击者只有 Token 仍然无法发起有效请求。
一、不要只绑定 device_id
最常见的做法是在请求中同时携带 Token 和 device_id：
Authorization: Bearer <token>
X-Device-ID: <device_id>
这种方式只能识别设备，不能证明请求真的来自该设备。攻击者拿到 Token 时，往往也能复制 device_id、请求头和客户端参数。
真正可靠的绑定必须依赖攻击者难以复制的凭证，通常是保存在设备安全区中的不可导出私钥。
服务器绑定的是设备公钥或公钥指纹；私钥始终留在客户端，不应上传。
二、设备绑定的基本流程
App 首次安装时生成非对称密钥对：
Android：Android Keystore，条件允许时使用硬件安全模块或 StrongBox
iOS：Keychain / Secure Enclave
Web：Web Crypto、WebAuthn 或 DPoP，但需要额外考虑 XSS 对密钥的威胁
用户登录后，服务端将 Refresh Token 或整个会话绑定到公钥指纹。后续请求除了携带 Token，还要附带由设备私钥生成的签名。
签名内容通常包含：
HTTP Method + URI + Token Hash + Timestamp + Nonce
服务端需要同时验证：
Token 是否有效、是否过期、是否已撤销。
签名公钥是否与 Token 绑定的公钥一致。
时间戳是否处于允许窗口。
Nonce 或请求唯一标识是否已经使用，防止重放。
攻击者即使复制了 Token，也无法在另一台设备上生成合法签名。
三、业内常绑定哪些信息
设备绑定通常分为三层：密码学强绑定、辅助风控和异常处置。
IP、设备型号、系统版本都会变化，也可能被伪造。它们适合做风险评分，不适合直接决定 Token 是否有效。
四、推荐落地方案
普通 App 可以采用下面的组合：
Access Token 保持短效，例如 5～30 分钟。
Refresh Token 绑定设备公钥指纹。
刷新 Token 时必须提供设备签名。
启用 Refresh Token Rotation，每次刷新后旧 Token 立即失效。
检测到旧 Refresh Token 被再次使用时，撤销对应 Token Family。
高风险接口要求重新输入密码、短信验证或 Passkey。
提供“已登录设备”页面，允许用户主动下线设备。
Android 配合 Play Integrity，iOS 配合 App Attest，作为辅助可信信号。
标准化方案优先考虑：
DPoP：在应用层通过公私钥证明 Token 持有者，适合 OAuth 客户端。
mTLS Certificate-Bound Token：通过客户端证书约束 Token，更常见于服务间调用、金融和企业系统。
不要自行发明复杂加密协议。确实需要自定义请求签名时，至少要覆盖请求方法、目标 URI、Token 哈希、时间戳和一次性随机数，并做好密钥轮换与重放检测。
五、设备绑定不能解决什么
设备绑定不是万能方案。如果攻击者已经控制原设备，能够在设备内调用私钥完成签名，服务端看到的请求仍可能合法。
因此它主要防止的是：
Token 被复制到其他设备使用
抓包或日志泄漏后的直接重放
数据备份、数据库泄漏导致的会话搬运
它不能替代终端安全、风控、短效 Token、权限控制和异常登录检测。
总结
只绑定 device_id 属于弱绑定，因为设备 ID 只是可以复制的标识。
更可靠的方案是：
设备安全区生成不可导出的私钥，服务端将 Token 绑定到公钥指纹，并要求客户端对请求生成持有证明。
实际项目中，再叠加短效 Access Token、Refresh Token Rotation、完整性校验和异常风控，才能形成完整的设备会话安全方案。
评论