白标Web应用选JWT还是Cookie会话？规避CORS及第三方Cookie问题

优先调研方向：Cookie + Session 方案 #

你关注的两个核心优势——更高的默认安全性、支持恶意操作时即时终止会话，都是Cookie方案原生支持的特性，对ToB白标场景的价值远高于JWT的跨域便利性。JWT本身存在无法原生作废会话、前端存储易被XSS攻击窃取、payload不可存敏感信息的天生缺陷，要补足这些特性需要额外实现Redis黑名单、过期时间强校验等逻辑，反而会抵消其开发便利性。

Cookie鉴权完全可以适配白标场景 #

你之前遇到的Auth0跨域Cookie问题，本质是Auth0下发的Cookie属于Auth0自身的第三方域名，和白标客户的域名无关联，才会被浏览器的第三方Cookie拦截规则限制。自研鉴权体系完全可以通过配置规避这个问题，两种可选落地方式：

• 给每个白标客户分配专属API子域名：例如客户前端域为my.whitelabel.com，配套分配api.whitelabel.com解析到你的API服务集群，将Session Cookie种在.whitelabel.com一级域名下，完全属于第一方Cookie，不会触发任何第三方Cookie拦截规则，CORS配置仅开放对应客户前端域名的访问权限即可。
• 统一API域名下适配跨域Cookie：如果不想为每个客户单独配置API域名，可将Cookie的SameSite属性设为None，同时强制开启Secure属性（仅在HTTPS环境下生效），当前所有主流浏览器都支持该配置，跨域请求时Cookie不会被拦截。

Cookie方案落地注意事项：

1. Session数据统一存储在Redis集群中，不要存在应用进程内存内，适配多实例部署、扩容需求，终止会话时直接删除Redis中对应的Session Key即可。
2. 必须为Cookie开启HttpOnly属性，禁止前端JS读取Cookie内容，从根源上规避XSS攻击窃取会话的风险。

如果你的白标客户存在大量端侧离线鉴权的特殊需求，再考虑评估JWT方案，其余场景下Cookie方案的综合收益更高。

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