OIDC重定向时Session Cookie丢失问题排查求助（Okta+Kerberos环境）

一、Kerberos与Okta交互的验证（无需关闭无代理SSO） #

• 导出chrome://net-export/完整日志后，重点排查Okta授权端点返回的重定向响应，确认响应头里的Set-Cookie是否包含服务器会话Cookie，以及该Cookie的Domain、Path、SameSite属性是否匹配客户环境的域名规则。
• 临时测试会话传递：生成state后，除存入Cookie，同时将state编码后附加到Okta授权请求的redirect_uri中（例如redirect_uri=https://your-app/callback?state_ref=xxx），回调时通过state_ref关联原始会话，验证能否正常获取state值。如果此方法有效，说明原Cookie传递被Kerberos或代理拦截。
• 检查Kerberos配置：确认客户的Kerberos SSO是否修改了浏览器Cookie策略，比如强制SameSite=Strict或限制跨域Cookie传递——Okta授权属于跨域请求，若Cookie的SameSite设为Strict，会导致重定向时无法携带会话Cookie。

二、代理影响的排查要点 #

• 对比正常与故障环境的代理规则：确认代理是否修改了Okta的重定向响应，比如移除或篡改Cookie头。可在故障环境中直接访问Okta授权端点（绕过代理），测试认证流程是否正常，以此排除代理干扰。
• 检查代理SSL解密配置：如果代理启用了SSL解密，可能导致Cookie的Secure属性失效，服务器无法识别会话Cookie。

三、State参数关联的重构方案 #

1. 服务器端维护有效State集合 #

• 生成state时，将其与临时生成的session_id绑定，存入服务器端缓存（如Redis、内存缓存），设置10分钟左右的过期时间。
• 授权请求时，将session_id附加到redirect_uri中（或编码进state本身），回调时通过session_id从缓存中取出对应state验证。
• 注意：session_id需具备足够的随机性和安全性，防止伪造。

2. 基于JWT的State编码 #

• 将state、会话标识、过期时间等信息编码为JWT，用服务器密钥签名后作为OIDC的state参数传递。
• 回调时，服务器验证JWT的签名和过期时间，直接解析出会话关联信息，无需依赖Cookie或服务器端缓存。
• 优势：无需维护额外缓存集合，减少服务器端状态依赖。

四、会话依赖关系的日志验证 #

针对你观察到的“重定向请求与原始请求无依赖”，可通过以下方式确认日志解读是否正确：

• 在正常和故障环境中，分别提取原始认证请求的Cookie头（含会话ID）和回调请求的Cookie头，对比两者的会话ID是否一致。
• 查看浏览器“开发者工具-网络”面板中回调请求的「发起者」字段，正常情况下应指向原始认证请求；若故障环境中发起者为other或无关联，说明浏览器未将两个请求关联到同一会话，大概率是Cookie未被正确携带。

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