【发布时间】：2021-09-10 11:52:42
【问题描述】：
我了解到，静默身份验证通常是在 1px iFrame 中进行的。我一直想知道的是如何将身份验证请求的响应从 iFrame 传递回父应用程序。我能想到的唯一选择是Auth-Server返回一些运行的javascript代码，例如
window.top.postMessage('auth', 'thisisthetoken')
但这种方法对我来说似乎有点草率。那么它是如何工作的呢？
【问题讨论】：
【发布时间】：2021-09-10 11:52:42
【问题描述】：
这是单页应用程序中令牌更新的传统流程。初始身份验证应通过重定向在主浏览器窗口上完成，例如 Google 登录或 Office 365。
代币更新库使用
oidc client library 通常用于实现这一点，使 iframe 发布只需很少的代码即可完成。
框架机制
主窗口在隐藏的 iframe 上触发 OpenID Connect 重定向。当收到响应时，iframe 使用 postMessage API 将 OpenID Connect 响应返回到主窗口，其中包含 code 和 state 参数。然后，主窗口使用 PKCE 代码验证程序交换令牌代码，该代码验证程序在触发 iframe 重定向之前保存到会话存储中。
第三方 Cookie 的浏览器支持
上述流程依赖于在 iframe 请求中发送的授权服务器的 SSO Cookie，但浏览器开始丢弃 third party cookies 以限制跟踪 - Safari 已经这样做了。
因此，现在的标准是通过为 Web 源站点发布的安全 cookie 来管理续订，并避免使用 iframe 发布解决方案。
如今依赖第三方 cookie 的项目将会遇到困难 - 请参阅 this recent answer of mine。
托管先决条件
在 2021 年，您最好在浏览器中使用安全的 SameSite cookie，因为在框架之间发布令牌很容易受到跨站点脚本的攻击。因此，确保每个框架的 Web 来源可以通过子域/同级域共享一个安全 cookie 是一个先决条件——如果没有它，这些天你就无法真正开发出一个安全的 Web 解决方案。
浏览器中的安全性是一个棘手的话题，需要架构设计 - 有关 2021 年网络安全建议的更多信息，请查看最近的 Curity Web Guidance。
仅使用令牌
在 2021 年购买被认为安全性非常差：
- 重定向整个窗口以验证用户身份（好）
- 将令牌保存到本地存储（坏） - 处理页面重新加载 - 很容易被恶意代码利用
- 然后在 iframe 之间发布令牌（错误）- 可以被添加侦听器的恶意代码拦截
【讨论】：
-
我正在构建的 webapp 使用多个 iFrame 作为组件。这些 iFrame 中的每一个都需要身份验证。出于安全原因，我不想将令牌从父级传递给每个 iFrame。这就是为什么我希望我的每个 iFrame 都进行身份验证。这就是为什么我不能对每个组件进行重定向。我的问题是出于好奇它是如何工作的。我知道那些图书馆有能力做到这一点。
-
是否只有加载 iframe 的初始请求被视为第三方请求，因此 cookie 被阻止？这是否意味着我可以加载身份验证服务器的身份验证页面，然后执行检查身份验证调用并返回令牌？由于页面的结构，我无法在 Web 来源的网站上使用安全 cookie。
-
我在上面添加了更多注释 - 基本上你不能依赖 SSO cookie（因为它是第三方） - 虽然（目前）它是通过完整的浏览 GET 重定向发送的。如果可能的话，我会在 Safari 上进行测试，因为它是最严格的浏览器。您可能需要与设计托管域的架构师等进行讨论。