SameSite=Strict下同域重定向丢失会话的问题排查请求

核心原因推测 #

当用户从跨站域名（ssoprocessing.com）重定向到ourdomain.com/login时，该请求属于跨站发起的顶级导航。此时在响应中设置SameSite=Strict的Cookie，部分现代浏览器会拒绝存储（遵循SameSite规范的严格判定），而SameSite=Lax允许这种场景下的Cookie设置。该异常Azure租户的重定向链可能触发了更严格的跨站判定，或者请求特性与其他租户存在差异，导致Cookie无法正常存储/携带。

排查步骤 #

• 抓包对比流程差异：
  • 用浏览器开发者工具（F12）捕获正常租户与异常租户的完整重定向请求链，重点查看ssoprocessing.com到ourdomain.com/login的请求方法（GET/POST）。若异常租户为POST请求，SameSite=Strict会直接阻止Cookie存储（Strict仅允许同站上下文的Cookie操作）。
  • 检查该请求的Referer、Origin头部，确认是否与正常租户存在差异，是否被浏览器判定为跨站级别更高的请求。
  • 在ourdomain.com/login响应后，查看Application > Cookies面板，确认会话Cookie是否存在。若未存储，查看控制台是否有Cookie blocked due to SameSite policy类错误提示。
• 检查Azure租户配置：
  • 对比异常租户与正常租户的OpenID重定向URI配置，确认是否存在路径、参数差异。
  • 查看Azure AD返回的授权码/id_token是否携带特殊字段，导致ssoprocessing.com生成的重定向请求与其他租户不同。
• 验证Cookie属性：
  • 确认会话Cookie是否同时设置Secure和HttpOnly属性（HTTPS环境下必须有Secure，否则浏览器可能拒绝存储），且域设置正确（比如若使用子域名，需设置为.ourdomain.com而非具体子域名）。

解决方案 #

• 调整重定向请求方法：若ssoprocessing.com到ourdomain.com/login的请求为POST，修改为GET（OpenID SSO流程中，令牌交换后的重定向规范为GET），SameSite=Strict允许同站GET导航的Cookie操作。
• 针对性设置SameSite属性：无需全局设置SameSite=Strict，针对SSO登录场景的会话Cookie临时设置为SameSite=Lax——因为SSO本身依赖跨站重定向，Strict规则并不适配这类跨站触发的登录流程。
• 修正Cookie域配置：若存在子域名差异（比如正常租户重定向到www.ourdomain.com，异常租户到ourdomain.com），将Cookie的Domain属性设置为.ourdomain.com，确保同域下所有子域名都能共享Cookie。

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