JWT vs Session/Cookies 最佳使用场景及技术问题咨询

1. 亚马逊、优步等超大规模平台的选型 & 分布式Session支撑能力 #

这类超大型平台不会采用单一的身份认证方案，会根据业务场景做混合适配：

• 面向C端用户的Web主站核心业务，普遍采用带HttpOnly、Secure、SameSite属性的Cookie存储会话ID + 后端分布式缓存（常用Redis集群）做Session存储的方案。
• 分布式缓存的Session方案完全可以支撑亿级用户量的访问需求：现在成熟的分布式缓存集群支持水平扩容、分片存储、热点Key优化、多地域副本同步，完全可以承载超高并发的会话查询请求，大厂还会做边缘节点缓存会话基础信息进一步降低中心缓存的压力，不存在性能瓶颈。
• 同时这类平台在内部微服务调用、移动端API、第三方开放平台、单点登录等场景，也会搭配使用JWT类的Token方案，兼顾不同场景的效率需求。

2. 优先选择JWT而非Session的业务场景 #

以下场景使用JWT的收益会明显高于Session方案：

• 微服务内部调用场景：JWT自带用户身份、权限字段，接收方只要校验签名即可获取身份信息，不需要每次都请求统一的Session中心查询，大幅降低跨服务调用的开销，也避免Session中心成为整体架构的单点瓶颈。
• 原生APP/客户端场景：APP本身不天然支持Cookie机制，将JWT存储在APP本地沙箱中比模拟Cookie逻辑的适配成本更低，且APP端不存在Web端的XSS注入风险，存储安全性更可控。
• 跨业务线单点登录场景：一次签发的JWT可以在多个独立部署的业务系统中通行，不需要每个业务系统都对接统一Session中心做身份校验，跨域名、跨业务线的适配成本远低于Session方案。
• 短有效期临时授权场景：比如生成10分钟有效的文件下载凭证、临时操作授权链接，JWT自带过期时间属性，签发后不需要服务端存储对应的会话记录，到期自动失效，比生成临时Session节省大量存储资源。
• 第三方开放API场景：给外部开发者提供的开放接口，用JWT做身份校验不需要为第三方维护会话状态，开发者只需要携带签发的Token即可发起请求，对接门槛更低。

内容的提问来源于stack exchange，提问作者EdH