为什么使用iFrame实现Silent Authentication？与直接发GET Request相比有什么优势？

静默认证的核心需求是在用户无感知的前提下，向身份提供商（Identity Server）获取当前用户的登录态或新令牌，全程不能打断用户当前页面的操作。和直接发送GET请求相比，隐藏iFrame的独有优势如下：

• 自动携带身份提供商域名下的Cookie
  浏览器同源Cookie策略默认限制：跨域请求直接发fetch/XMLHttpRequest的话，需要手动配置withCredentials才会携带第三方Cookie，且如果遇到浏览器第三方Cookie拦截策略，跨域异步请求的Cookie传递很容易失败。而iFrame加载身份提供商的认证端点属于正常的页面导航行为，会自动携带对应域名下的所有Cookie，不需要额外配置，兼容性更强。
• 自动处理身份提供商的302跳转逻辑
  大部分身份提供商的认证流程都会涉及多次302重定向，比如先跳转到会话校验端点、再跳转到令牌下发地址，直接用异步GET请求处理跨域重定向会触发CORS预检校验，很容易因为跨域规则限制被拦截。iFrame天然支持页面重定向逻辑，会自动跟进所有302跳转，不需要手动处理重定向流程，完全适配身份提供商的标准认证跳转逻辑。
• 降低令牌泄露风险
  直接发GET请求如果返回的是包含令牌的响应，很容易被页面上的恶意脚本、XSS漏洞窃取。用iFrame的话，可以通过postMessage仅在iFrame和父页面之间传递必要的认证结果，令牌可以完全在iFrame的隔离上下文里处理，不会暴露到父页面的全局作用域，安全性更高。
• 兼容旧版本身份认证协议
  部分旧版本的OAuth2/OIDC实现没有提供专门的静默刷新接口，只支持通过浏览器页面访问的方式下发令牌，这种场景下异步GET请求根本无法完成认证流程，只有iFrame可以模拟正常的页面访问流程完成静默认证。
• 完全无感知不干扰当前页面状态
  隐藏的iFrame不会渲染任何可见内容，也不会触发当前页面的跳转、刷新，整个认证流程完全在后台完成，用户根本感知不到操作，完全符合静默认证的核心要求。

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