Appearance
认证模型：Session、Cookie、Token 与前端存储边界
主题定位
认证相关问题很容易被讲成一句“Token 放哪里更安全”，但这其实把好几个层级压扁了。Session、Cookie、Token 分别描述的是服务端状态、浏览器携带机制和凭证表达方式，它们本来就不在同一层。
- 认证相关问题很容易被讲成一句“Token 放哪里更安全”，但这其实把好几个层级压扁了。Session、Cookie、Token 分别描述的是服务端状态、浏览器携带机制和凭证表达方式，它们本来就不在同一层
- 这道题经常被追问，是因为它天然会牵动 XSS、CSRF、跨域、刷新令牌、登出失效和多标签页同步
- 如果不能先把概念层级拆开，后面一旦问到“为什么不用另一种方式”，答案会迅速失真
- 真正成熟的回答，必须同时交代凭证如何传、谁能读、谁来失效、以及出了问题会暴露什么攻击面
Session、Cookie、Token 各自解决什么问题
Session
Session 先看职责边界，再看生命周期、数据形态和与其他对象的协作关系。 Session 的差异最终会体现在 协议语义、连接代价、失败恢复 这几个维度。 Session 讲清适用边界、失效条件和代价结构，结论才有技术含量。
Cookie
Cookie 先看职责边界，再看生命周期、数据形态和与其他对象的协作关系。 Cookie 的差异最终会体现在 协议语义、连接代价、失败恢复 这几个维度。 Cookie 讲清适用边界、失效条件和代价结构，结论才有技术含量。
Token
Token 先看职责边界，再看生命周期、数据形态和与其他对象的协作关系。 Token 的差异最终会体现在 协议语义、连接代价、失败恢复 这几个维度。 Token 讲清适用边界、失效条件和代价结构，结论才有技术含量。
认证边界与存储取舍
- 这道题经常被追问，是因为它天然会牵动 XSS、CSRF、跨域、刷新令牌、登出失效和多标签页同步
- 如果不能先把概念层级拆开，后面一旦问到“为什么不用另一种方式”，答案会迅速失真
- 真正成熟的回答，必须同时交代凭证如何传、谁能读、谁来失效、以及出了问题会暴露什么攻击面
- 优点是服务端控制力强，失效、下线、权限回收都更直接
- 代价是服务端需要维护状态，扩容和多节点同步时要考虑会话存储
- 如果 Cookie 承担的是 Session ID，那么它服务的是服务端会话模型
工程设计建议
- 这道题经常被追问，是因为它天然会牵动 XSS、CSRF、跨域、刷新令牌、登出失效和多标签页同步
- 如果不能先把概念层级拆开，后面一旦问到“为什么不用另一种方式”，答案会迅速失真
- 真正成熟的回答，必须同时交代凭证如何传、谁能读、谁来失效、以及出了问题会暴露什么攻击面
- 优点是服务端控制力强，失效、下线、权限回收都更直接
- 代价是服务端需要维护状态，扩容和多节点同步时要考虑会话存储
问答设计及延伸
标准回答
回答 认证模型：Session、Cookie、Token 与前端存储边界 时，先定义 Session、Cookie、Token 各自解决的问题，再比较它们在 协议语义、连接代价、失败恢复 上的差异，最后给出选型边界和工程代价。
追问拆解
- 认证模型：Session、Cookie、Token 与前端存储边界 与“CORS 与跨域：同源策略、预检、凭证模式与缓存影响”的边界关系
- 认证模型：Session、Cookie、Token 与前端存储边界 与“浏览器存储：Cookie、localStorage、sessionStorage、IndexedDB 与配额边界”的边界关系
- 认证模型：Session、Cookie、Token 与前端存储边界 与“XSS 与 CSRF：脚本注入和跨站请求伪造的边界”的边界关系
- 跨标签页、跨域、多端协作场景下的结论变化
- 维护成本上升后的优先级调整
容易失分的点
- 只给“哪个好”的结论，不先拆对象
- 只报 API 或术语，不解释运行时行为和代价
- 缺少真实场景，导致结论过度绝对
项目映射
- 结合真实系统说明 Session 到 Token 分别落在哪段链路
- 补充未选方案的放弃原因和约束差异
- 补充线上问题、治理动作和验证结果