会话管理 OpenID Connect 为什么有两个 Iframe？

Question

我一直在阅读描述如何处理用户注销的 OpenID Connect 规范草案。一切都指向这个超级奇怪的两个 iframe 解决方案。看这里： openid spec for sessions 并在此处进行简要说明： Hans Zandbelt blog regarding this strategy

有人可以解释为什么我需要两个单独的 iframe，而不仅仅是一个到 openid 身份提供商，还有一些 javascript 在我的页面上删除 cookie 并重定向到 sso 登录吗？

Answer 1

删除本地会话的触发器位于不同的域中，即 OpenID Connect 提供商的域。因此，要了解那里发生的变化，您需要 "poll" 涉及所谓 "cross-domain" 通信的提供商。为了避免以大量网络流量开销不断轮询远程 URL，我们的想法是通过检查提供者的 cookie 在本地轮询状态更改。这是通过利用 iframe 之间的 postMessage 通信框架来完成的，因为只有 OP 提供的代码才能检查 OP 的 cookie。

Answer 2

前几天我也有同样的疑问，为什么我们需要两个 iframe 来执行会话检查。在我看来，RP iframe 完全没用。事实上，仅使用指向 check_session_iframe url.

的 iframe 执行会话检查是完全可能的

事实是，当您收到 changed 消息时，您很可能想要尝试静默令牌续订，正如规范所述，并且您需要一个 iframe 才能这样做，因此RP iframe.

spec (4.1 RP Iframe) 说：

Upon receipt of changed, the RP MUST perform re-authentication with 
prompt=none to obtain the current session state at the OP. 

When the RP detects a session state change, it SHOULD first try a prompt=none 
request within an iframe to obtain a new ID Token and session state, sending 
the old ID Token as the id_token_hint.

我相信 RP iframe 负责在收到更改的消息后执行静默令牌更新。然后 RP iframe 应该生成一个带有 prompt=none 的新令牌请求，因此是静默部分。如果 RP iframe 无法静默更新令牌，则用户不再经过身份验证，应通知您的应用程序执行适当的操作。

会话管理 OpenID Connect 为什么有两个 Iframe？

Session Management OpenID Connect Why two Iframes?

session

openid-connect