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

Question

我一直在阅读描述如何处理用户注销的OpenID Connect草案规范.一切都指向这个超级奇怪,两个iframe解决方案.请参阅此处: 会话的openid规范 和简要说明: Hans Zandbelt关于此策略的博客

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

Answer 1

前几天我有同样的疑虑,为什么我们需要两个iframe来执行会话检查.从我的角度来看,RP iframe完全没用.事实上,只使用指向check_session_iframeurl 的iframe执行会话检查是完全可能的.

问题是,当您收到changed消息时,您很可能想要尝试静默令牌续订,正如规范所说,并且您将需要一个iframe来执行此操作,因此需要RP iframe.

该规范(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无法以静默方式续订令牌,则不再对用户进行身份验证,并且应通知您的应用程序执行适当的操作.

Answer 2

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