后端面试：如何把现有 Cookie 登录升级为设备绑定会话？
题干与适用场景
一个已有登录系统使用长期 Cookie 维持会话。安全团队希望降低窃取 Cookie 后的跨设备冒用风险，但不能要求所有客户端同时升级，也不能让密钥轮换、浏览器重启或设备恢复导致大面积登出。请设计 DBSC 接入方案，覆盖注册、刷新、撤销、降级、审计和灰度发布。
面试官考察点
- 是否区分长期身份会话、短期授权 Cookie 和设备私钥。
- 是否能说清注册端点、刷新端点、挑战应答和服务端绑定记录。
- 是否处理私钥不可导出、浏览器不支持、Cookie 缺失和设备迁移。
- 是否设计撤销、密钥轮换、并发刷新和异常检测。
- 是否把兼容性与安全边界写进灰度、监控和回滚流程。
回答前需要澄清的问题
- 哪些账户或操作必须强制设备绑定，哪些可以继续使用普通 Cookie？
- 会话最长存活时间、短期 Cookie 的刷新周期和可接受的重新登录率是多少？
- 是否支持多设备并存、企业代理、无 TPM 设备和跨站子域？
- 发现证明失败时是立即登出、降级到 MFA，还是冻结高风险操作？
- 现有网关能否透传注册与刷新响应头，日志中哪些字段允许留存？
30 秒回答框架
“我会保留现有登录态作为兼容层，在登录成功后通过 Secure-Session-Registration 请求浏览器创建设备密钥。服务端只保存公钥、会话标识、刷新端点、作用域和状态，并把长期 Cookie 换成短期 Cookie。短期 Cookie 到期时，浏览器向刷新端点发起带密钥证明的请求，服务端验证签名、挑战、会话和风控后签发新 Cookie。注册或刷新失败时按设备能力与风险降级到普通会话或 MFA；撤销、轮换、审计和灰度指标决定是否扩大启用范围。”
分步骤深入解答
1. 定义信任边界与状态
登录服务仍负责用户认证，DBSC 层负责证明当前浏览器持有与会话绑定的私钥。服务端记录 sessionId、公钥、密钥版本、刷新端点、作用域、短期 Cookie 名称、状态和最后证明时间；不保存私钥，也不把公钥当作用户身份本身。
2. 注册设备绑定会话
登录成功响应携带注册响应头。浏览器生成密钥对，并把公钥提交到注册端点。服务端校验一次性注册令牌、登录会话和来源，写入绑定记录，然后返回 JSON 会话配置与短期 Cookie。注册操作必须幂等，重复提交不能生成无法撤销的孤儿绑定。
Secure-Session-Registration: (ES256); path="/StartSession"
Set-Cookie: auth_cookie=short-lived; Max-Age=600; Secure; HttpOnly; SameSite=Lax3. 刷新时验证密钥证明
短期 Cookie 即将过期时，浏览器调用刷新端点并携带 DBSC proof JWT。服务端检查签名算法、挑战值、会话标识、时间窗口、密钥版本和作用域，再原子地推进挑战或刷新计数。验证失败不能静默延长旧 Cookie，应返回可观测的失败原因并进入风险策略。
4. 处理降级与多设备
DBSC 是增量能力。浏览器或硬件不支持时保留普通会话，但高风险操作可要求 MFA。多设备对应多个绑定记录，用户撤销某一设备只删除该记录；全局退出则撤销用户所有绑定和普通会话。降级路径必须设置较短的生命周期与速率限制，避免成为绕过点。
5. 设计轮换、并发与恢复
密钥轮换创建新版本并保留短暂重叠窗口，旧版本只允许一次受控迁移。刷新请求使用会话级锁或版本条件更新，避免并发请求互相覆盖挑战。浏览器恢复、清除站点数据或私钥丢失时，服务端撤销旧绑定并要求重新认证；不能把“刷新失败”直接当成永久封禁。
6. 监控、审计与灰度
记录注册成功率、证明失败率、刷新延迟、降级比例、设备撤销原因和按浏览器版本分布，但不记录私钥。先对低风险账户灰度，比较会话劫持告警与登录成功率；异常升高时关闭注册响应头即可停止新增绑定，保留普通 Cookie 兼容路径。所有策略和密钥版本变更写入不可变审计记录。
高质量示范回答
“DBSC 层只证明浏览器持有与会话绑定的私钥，用户认证仍由原登录系统完成。登录后，服务端通过注册响应头让浏览器生成密钥并提交公钥，再把长期 Cookie 换成短期 Cookie。刷新端点验证 proof JWT 的签名、挑战、会话、时间和作用域，原子推进挑战后签发新 Cookie。服务端保存公钥、状态、版本和审计信息，不保存私钥。多设备用独立绑定记录，撤销可以按设备或全局执行；不支持 DBSC 的客户端走受限普通会话或 MFA。灰度阶段监控证明失败、降级和登录成功率，出现异常时去掉注册响应头并保留兼容路径。”
常见错误
- 把公钥当作用户身份 → 设备绑定记录与认证主体混淆 → 公钥只作为会话证明材料。
- 只把长期 Cookie 改短 → 窃取者仍可在有效期内冒用 → 短期 Cookie 必须和私钥证明绑定。
- 刷新端点不做挑战重放保护 → 同一证明可被重复使用 → 绑定一次性挑战、时间窗和原子状态更新。
- 不支持就强制登出所有人 → 兼容性和可用性风险过大 → 按能力与风险降级到普通会话或 MFA。
- 把 DBSC 当成不可撤销凭证 → 设备丢失后无法隔离风险 → 提供设备级、用户级撤销和审计。
追问及应对
私钥真的能防住所有 Cookie 窃取吗？
不能。DBSC 主要降低把 Cookie 导出到另一台设备后直接冒用的风险；已控制原设备的恶意软件、登录过程中的攻击或服务端失陷仍需其他防护。回答应明确威胁模型和残余风险。
为什么服务端还要保留普通会话路径？
浏览器、硬件和企业网络能力不一致，且 DBSC 仍处于标准演进阶段。保留受限兼容路径可避免全量登出；高风险操作可以提高验证要求，而不是让登录系统失效。
如何防止并发刷新导致会话错乱？
按 sessionId 和密钥版本做条件更新，只接受当前挑战，成功后原子写入下一挑战与 Cookie 版本。重复请求返回同一结果或要求重新刷新，避免两个响应互相覆盖。
设备迁移或恢复备份时怎么办？
把它当成新设备注册，而不是复制旧私钥。旧绑定可以保留短暂宽限期并触发风控；完成重新认证后再建立新公钥绑定，用户可在设备管理页撤销旧记录。