我一直在阅读描述如何处理用户注销的OpenID Connect草案规范。一切都指向这个超级奇怪的，两个iframe解决方案。看这里： openid spec for sessions 这里有一个简短的描述： Hans Zandbelt blog regarding this strategy
有人可以解释为什么我需要两个单独的iframe，而不仅仅是一个openid身份提供者，以及我页面上的一些javascript删除cookie并重定向到sso登录？
答案 0 :(得分：6)
前几天我有同样的疑虑，为什么我们需要两个iframe来执行会话检查。从我的角度来看，RP iframe完全没用。事实上，仅使用指向check_session_iframe网址的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无法以静默方式续订令牌，则不再对用户进行身份验证，并且应通知您的应用程序执行正确的操作。
答案 1 :(得分：1)
删除本地会话的触发器位于不同的域中，即OpenID Connect Provider的域。因此，要了解那里发生的变化，您需要＆＃34;民意调查＆＃34;提供商涉及所谓的跨域＆＃34;通讯。为了避免在网络流量开销过大的情况下不断轮询远程URL，我们的想法是通过检查提供商的cookie来在本地轮询状态更改。这是通过利用iframe之间的postMessage通信框架来完成的，因为只有OP提供的代码才能检查OP的cookie。