来自 IFrame 的静默身份验证反馈
Silent Authentication feedback from IFrame
我读到静默身份验证通常在 1px iFrame 中进行。我一直想知道的是如何将对身份验证请求的响应从 iFrame 传回父应用程序。我能想到的唯一选择是 Auth-Server returns 一些 javascript 运行的代码，例如
window.top.postMessage('auth', 'thisisthetoken')
但我觉得这种方法有点草率。那么它是如何工作的呢？
这是单页应用程序中令牌续订的传统流程。初始身份验证应通过重定向在主浏览器 window 上完成，例如 Google 登录或 Office 365。
令牌更新库使用
oidc client library 通常用于实现这一点，使 iframe post 只需很少的代码即可完成。
IFRAME 机制
主要 window 在隐藏的 iframe 上触发 OpenID Connect 重定向。当收到响应时，iframe 使用 postMessage API 到 return OpenID Connect 响应到主 window，包含 code 和 state 参数。主 window 然后使用 PKCE 代码验证器交换令牌代码，该验证器在触发 iframe 重定向之前保存到会话存储中。
浏览器对第三方 Cookie 的支持
以上流程依赖于在 iframe 请求中发送的授权服务器的 SSO Cookie，但浏览器开始放弃 third party cookies 以限制跟踪 - Safari 已经这样做了。
因此，现在标准是通过为 Web 源站点发布的安全 cookie 来管理续订，并避免 iframe post 解决方案。
这些天依赖第三方 cookie 的项目将很困难 - 请参阅 。
托管先决条件
2021 年，您最好在浏览器中使用安全的 SameSite cookie，因为 post 在框架之间输入令牌很容易受到跨站点脚本攻击。因此，确保每个框架的 Web 来源可以通过子域/兄弟域共享安全 cookie 是一个先决条件 - 如果没有它，您现在无法真正开发安全的 Web 解决方案。
浏览器中的安全性是一个棘手的话题，需要架构设计 - 有关 2021 年网络安全建议的更多信息，请查看最近的 Curity Web Guidance。
只有代币
2021 年这会奏效购买被认为安全性很差：
- 重定向整个 window 以验证用户（好）
- 将令牌保存到本地存储（坏）- 处理页面重新加载- 容易被恶意代码利用
- 然后 post iframe 之间的令牌（坏）- 可以被添加侦听器的恶意代码拦截
我读到静默身份验证通常在 1px iFrame 中进行。我一直想知道的是如何将对身份验证请求的响应从 iFrame 传回父应用程序。我能想到的唯一选择是 Auth-Server returns 一些 javascript 运行的代码，例如
window.top.postMessage('auth', 'thisisthetoken')
但我觉得这种方法有点草率。那么它是如何工作的呢？
这是单页应用程序中令牌续订的传统流程。初始身份验证应通过重定向在主浏览器 window 上完成，例如 Google 登录或 Office 365。
令牌更新库使用
oidc client library 通常用于实现这一点，使 iframe post 只需很少的代码即可完成。
IFRAME 机制
主要 window 在隐藏的 iframe 上触发 OpenID Connect 重定向。当收到响应时，iframe 使用 postMessage API 到 return OpenID Connect 响应到主 window，包含 code 和 state 参数。主 window 然后使用 PKCE 代码验证器交换令牌代码，该验证器在触发 iframe 重定向之前保存到会话存储中。
浏览器对第三方 Cookie 的支持
以上流程依赖于在 iframe 请求中发送的授权服务器的 SSO Cookie，但浏览器开始放弃 third party cookies 以限制跟踪 - Safari 已经这样做了。
因此，现在标准是通过为 Web 源站点发布的安全 cookie 来管理续订，并避免 iframe post 解决方案。
这些天依赖第三方 cookie 的项目将很困难 - 请参阅
托管先决条件
2021 年，您最好在浏览器中使用安全的 SameSite cookie，因为 post 在框架之间输入令牌很容易受到跨站点脚本攻击。因此，确保每个框架的 Web 来源可以通过子域/兄弟域共享安全 cookie 是一个先决条件 - 如果没有它，您现在无法真正开发安全的 Web 解决方案。
浏览器中的安全性是一个棘手的话题，需要架构设计 - 有关 2021 年网络安全建议的更多信息，请查看最近的 Curity Web Guidance。
只有代币
2021 年这会奏效购买被认为安全性很差：
- 重定向整个 window 以验证用户（好）
- 将令牌保存到本地存储（坏）- 处理页面重新加载- 容易被恶意代码利用
- 然后 post iframe 之间的令牌（坏）- 可以被添加侦听器的恶意代码拦截