我一直在阅读描述如何处理用户注销的OpenID Connect规范草案。所有内容都指向这个超级奇怪的双iframe解决方案。请参见此处：会话的openid规范并在此进行简要说明：Hans Zandbelt关于这一策略的博客
有人能解释一下为什么我需要两个单独的iframe，而不仅仅是一个到openid身份提供者，以及我页面上的一些javascript来删除cookie并重定向到sso登录吗？
前几天我也有同样的疑问，为什么我们需要两个iframe来执行会话检查。从我的角度来看，RP iframe完全没有用。事实上，只需要一个指向check_session_iframe url的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无法静默地续订令牌，则用户将不再经过身份验证，并且应该通知您的应用程序执行正确的操作。
删除本地会话的触发器位于另一个域中，即OpenID Connect Provider的域。因此，要了解那里发生的变化，您需要"轮询"提供商，这涉及所谓的"跨域"通信。为了避免在网络流量开销较大的情况下不断轮询远程URL，我们的想法是通过检查提供者的cookie来在本地轮询状态更改。这是通过利用iframe之间的postMessage通信框架来实现的，因为只有OP提供的代码才能检查OP的cookie。