不同域名的系统怎样实现 SSO？为什么不能直接共享 localStorage？
先理解原理和示例，再练习完整口述与追问。
回答要点
同源存储不能跨任意域共享；中央身份提供方；一次性授权码/票据与回调校验；state、PKCE、服务端会话；控制重定向地址。
原理拆解
不同 origin 的 localStorage 不能直接互读，Cookie 也不能跨无关注册域随意共享。常见方案是各业务系统信任统一身份提供方：用户访问应用发现未登录后，被重定向到身份提供方；身份提供方已有登录会话时完成授权，带短期、一次性授权码返回已登记的回调地址，应用通过规范流程兑换并验证结果，再建立自己的会话。
使用 OpenID Connect 时，应在 OAuth 授权码流程基础上处理身份信息；浏览器公共客户端通常使用 PKCE，敏感应用可由后端完成兑换并使用 HttpOnly、Secure、适当 SameSite 的会话 Cookie。state 用于关联发起与回调、防止登录 CSRF；OIDC 中还需要按所用流程校验 nonce、签名、issuer、audience、有效期等。不能仅解析一段 JWT 内容就信任身份，JWT 签名也不代表负载已加密。
回调 URL 必须严格登记和校验，授权码一次性使用、短期有效，不把长期访问令牌放到可泄漏的 URL 或日志中。页面按钮隐藏不是授权，后端每个请求都要校验权限。跨站 Cookie 限制、退出传播、会话过期与账号切换要按协议处理，不能依赖第三方 Cookie 永远可用；自建票据方案也必须具备同等级别的签发、校验、绑定、重放防护和审计，优先采用成熟标准实现。
示例与推演
应用 A 与 B 各自维护会话，登录统一跳到身份提供方；已登录用户得到短期一次性授权码，应用按协议兑换并验证后建立本域会话。state 关联发起与回调，PKCE 绑定授权码兑换，ID Token 还需正确验证签名、issuer、audience 和时效。
易错点
JWT 内容可读不代表被篡改可接受，更不代表已加密。不要在无关域间靠手工复制长期 token 或共享 localStorage 设计 SSO。
参考回答可直接练习口述
不同 origin 的 localStorage 不能直接互读，Cookie 也不能跨无关注册域随意共享。常见方案是各业务系统信任统一身份提供方：用户访问应用发现未登录后，被重定向到身份提供方；身份提供方已有登录会话时完成授权，带短期、一次性授权码返回已登记的回调地址，应用通过规范流程兑换并验证结果，再建立自己的会话。