基于oidc-provider与oidc-client-ts的HttpOnly Cookie场景SSO实现疑问

问题1：HttpOnly Cookie在同子域/跨域应用间的传递策略 #

同子域应用（如app1.example.com、app2.example.com） #

• 配置oidc-provider的会话Cookie时，将Domain属性设为父域名（如.example.com），Path设为/，确保同子域下的所有应用都能接收到该HttpOnly Cookie。浏览器会自动在向同子域发起请求时携带这个Cookie。
• 注意设置SameSite属性：若应用都是同站请求，设为Lax即可；若存在跨站跳转需求，需设为None并配合Secure属性（仅HTTPS环境有效）。

外部域名（跨域）应用 #

跨域场景下浏览器遵循同源策略，无法直接传递不同域名的HttpOnly Cookie，可采用以下替代策略：

• 依赖oidc-provider的会话实现SSO：外部应用发起授权请求到oidc-provider时，用户已在provider端登录（provider通过自身域名下的HttpOnly Cookie维护会话），provider会直接返回授权码，无需用户重新登录。外部应用拿到授权码后换取自身的token，并通过自己的HttpOnly Cookie维护本地会话。
• iframe会话检查机制：在外部应用中嵌入一个指向oidc-provider会话检查接口的iframe，iframe与provider同域，会自动携带provider的HttpOnly Cookie。接口验证会话有效后，通过postMessage通知父应用用户已登录，触发授权流程。
• 避免跨域Cookie共享：不要尝试通过第三方Cookie等方式跨域传递HttpOnly Cookie，这类方式浏览器限制越来越严格，且存在安全风险。

问题2：oidc-provider识别已登录用户的逻辑 #

• oidc-provider在用户首次登录成功后，会在自身域名下设置专属的HttpOnly会话Cookie，用来存储用户的登录会话信息（如会话ID、过期时间等）。
• 当其他应用发起/authorize授权请求时，浏览器会自动携带provider域名下的HttpOnly Cookie到provider服务器。
• provider验证该Cookie的有效性（检查会话是否存在、未过期、签名合法等），若验证通过，则直接识别用户已登录，跳过登录页面，返回授权码给应用。
• 核心逻辑：用户的登录状态由oidc-provider统一维护，应用无需共享登录Cookie，只需触发授权请求即可让provider完成登录状态校验。

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