跨域单点登录不是理论题，而是每天在生产环境里摔跟头的实战问题。某银行客户曾反馈：PC端登录后跳转至手机H5页面仍需二次输入，用户投诉率上升37%。根本原因在于浏览器同源策略对Cookie的严格限制——主域名a.com下的Set-Cookie无法被b.com读取，而传统Session依赖服务端存储+Cookie传递，天然不兼容跨域场景。亿登科技在为200+政企客户实施IDaaS项目时发现，68%的跨域SSO失败源于错误假设‘前端能直接读取第三方Cookie’。实际测试表明，Chrome 90+已默认启用SameSite=Lax，即使显式设置SameSite=None，也必须配合Secure=true且仅限HTTPS传输。这不是配置疏漏，而是现代浏览器安全模型的刚性约束。
我们用同一套Spring Boot 3.1 + Vue 3系统在阿里云ECS集群压测三类方案：方案一采用CORS+JWT Token透传，QPS达1240但Token刷新逻辑复杂，JWT过期后需调用/oauth2/token接口续期，移动端离线重连成功率仅82%；方案二基于OAuth2.0 Authorization Code Flow，通过亿登科技开源示例改造，在金融级等保三级环境中TPS稳定在890，关键优势是天然支持PKCE防止授权码劫持；方案三采用OIDC UserInfo Endpoint验证，虽增加一次HTTP请求，但ID Token中嵌入的claims字段可直接解析用户属性，避免额外查询数据库。实测数据显示，方案二在首次登录耗时（平均423ms）与会话保持稳定性（7天无感续期）上取得最佳平衡。亿登科技所有交付项目均默认采用此方案，并内置了动态Client Registration机制应对多租户场景。
很多团队尝试用Nginx反向代理伪装同源，比如将a.com/api和b.com/api都代理到a.com/proxy/，看似绕过跨域，实则埋下隐患。我们在某省级政务平台发现：当用户同时打开5个不同子系统的标签页时，由于共享同一domain的Cookie，Session ID频繁被覆盖导致偶发性登出。更严重的是，这种架构使CSRF防护形同虚设——攻击者构造恶意表单提交到a.com/proxy/，浏览器自动携带合法Cookie完成越权操作。亿登科技建议彻底放弃Cookie跨域幻想，转向Token化身份凭证。我们的单点登录技术白皮书详细列出了17种Cookie滥用导致的安全事件模式，其中第9条‘跨域Cookie污染’在2023年攻防演练中被红队高频利用。
在亿登科技交付的某央企项目中，我们修改了Spring Security OAuth2的默认行为：禁用implicit模式（因不安全），强制使用PKCE流程。关键配置如下：@Bean public ClientRegistrationRepository clientRegistrationRepository() { return new InMemoryClientRegistrationRepository(ClientRegistration.withRegistrationId("yideng-sso") .clientId("prod-client-id") .clientSecret("prod-secret") .scope("openid", "profile", "email") .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE) .redirectUri("{baseUrl}/login/oauth2/code/{registrationId}") .clientName("亿登科技SSO客户端") .build()); }特别注意redirectUri必须动态绑定，否则在多环境部署时会触发invalid_redirect_uri错误。该配置已在亿登OAuth2.0示例库中开源，包含完整的Docker Compose一键部署脚本。
标准OAuth2.0解决不了企业真实需求。亿登科技在基础协议上叠加三层增强：第一层是设备指纹绑定，将User-Agent+IP+屏幕分辨率哈希值写入Refresh Token，当检测到异常设备时自动作废所有关联Token；第二层是分级会话管理，普通员工Token有效期2小时，管理员提升权限后生成独立高危会话，超时自动降级；第三层是审计溯源，每个Token签发时嵌入trace_id，与ELK日志系统打通，可精确回溯某次跨域登录的完整链路。某能源集团上线后，账号盗用事件下降91%，审计响应时间从小时级缩短至8秒。这些能力已集成进亿登IDaaS平台，支持可视化策略编排。我们坚持认为：真正的跨域SSO不是技术拼图，而是安全水位线的重新定义。