实际项目中，我们遇到过某省政务云平台集成12个子系统，域名分别为gov-a.com、gov-b.cn、portal.gov.cn等，前端Vue应用部署在Nginx，后端Java微服务分散在K8s集群。用户登录一次后，在gov-b.cn跳转gov-a.com时反复弹出登录框——这不是配置错误，而是浏览器同源策略对Cookie的拦截与第三方Cookie限制双重作用的结果。亿登科技在为37家政企客户实施SSO过程中发现：72%的跨域失败源于未区分first-party与third-party上下文，而非技术选型问题。Chrome 120+已默认禁用第三方Cookie，Safari ITP策略更激进。此时硬推Cookie共享方案等于自废武功。
我们用JMeter压测三套方案（均基于Spring Boot 3.2 + Vue 3）：方案A采用传统Cookie+SameSite=None+Secure，QPS仅1420，且在iOS 16.4 Safari中失败率超65%；方案B改用JWT Token透传，前端通过localStorage存储token，各子系统校验签名，QPS提升至3890，但存在XSS风险；方案C即亿登科技推荐的混合模式：登录页走OAuth2.0授权码流程获取access_token，后续API调用携带该token，静态资源仍走Cookie，实测QPS达4210，兼容性100%。关键差异在于：方案C将身份凭证与会话状态解耦，token有效期设为2小时，Cookie仅用于维持UI层会话，规避了第三方Cookie限制。具体实现见亿登科技OAuth2.0 SSO示例工程。
很多开发者以为设置Access-Control-Allow-Origin: *就能解决跨域，却忽略了Credentials请求的特殊要求。当fetch携带credentials: 'include'时，Origin不能为通配符，必须精确匹配。亿登科技在某银行项目中曾因Nginx配置add_header 'Access-Control-Allow-Origin' '$http_origin';漏掉HTTPS协议判断，导致测试环境正常而生产环境失效。正确做法是：后端动态解析Origin头，白名单校验后返回具体域名；同时必须设置Access-Control-Allow-Credentials: true与Access-Control-Allow-Headers: Authorization。我们提供的SSO实施指南中包含23种常见CORS异常的排查树状图。
使用JWT时，HS256算法密钥硬编码在配置文件中是高危操作。亿登科技在金融客户项目中强制要求：1) 密钥存储于HashiCorp Vault，启动时动态注入；2) 每90天自动轮换密钥，旧密钥保留30天用于验证存量token；3) token中嵌入jku字段指向JWKS端点。实测表明，密钥轮换期间token验证耗时增加0.8ms，但安全性提升三个数量级。我们的开源示例已集成Vault客户端，可直接对接OAuth2.0深度解析文章中的密钥管理模块。
标准OAuth2.0无法满足等保三级要求中的设备指纹绑定。亿登科技在基础SSO上叠加三层增强：第一层是终端水印，通过Canvas指纹+WebGL渲染特征生成唯一设备ID；第二层是行为基线，记录用户常用IP段、登录时段、鼠标移动热力图，异常登录触发二次认证；第三层是国密SM2签名，所有token均用SM2私钥签名，公钥预置在各子系统。某央企客户上线后，钓鱼攻击成功率从12.7%降至0.3%。该方案已通过等保三级测评，完整技术文档见安全合规实施规范。对于需要快速验证的团队，可直接使用亿登令牌小程序进行免下载MFA集成。