iframe - 这个身份验证流程安全吗？

Question

目标

在第 3 方网站上嵌入一个表单，该表单可以使用第 1 方身份验证(OIDC、keycloak)发布到通过不记名 token 保护的第 1 方服务。 (想想像 la disqus 的评论形式。)

此流程不允许刷新 oidc 不记名 token 是可以接受的。

疑虑

1. 防止点击劫持

2. 控制允许使用表单的第 3 方网站

3. 从第 3 方网站隔离用户信息和 token

方法

我目前的理解使我相信问题已经得到解决:

1. 为了防止点击劫持(就像在 iframe 嵌入式身份验证中一样)，整个登录过程都在一个新的弹出窗口中执行(见图:打开弹出窗口)。

2. 检查 window.opener 并根据 pass-list 检查 window.opener(参见图片:登录登陆)应确保登录登陆未嵌入 iframe，未直接导航至，并且仅从授权网站的弹出窗口中访问。检查 window.postmessage 命令的 targetOrigin 应该确保只有授权的网站才能成功使用该表单。

3. 让网络组件(参见图片:第一方网络组件)使用来自 srcDoc 的内部沙盒 iframe 来执行所有用户信息或 token 相关操作，应该保护用户信息和 token 不被第 3 方访问网站。使用内部 iframe 还应确保使用 Web 组件的第 3 方网站无法拦截消息后事件。

问题

1. 该方法安全吗？

2. 是否有我不知道的更标准化的方法来解决这个问题？

感谢您的输入!

Answer 1

好的，您每天都会学到新东西。

我了解到，问题中所示的方法不安全。

• 通过 srcdoc 填充的 iframe 显然不算作跨域框架。好吧，呃。这意味着它无法针对第 3 方网站提供可行的保护。这并没有通过在其上设置沙箱属性得到任何改善，因为这是为了提供另一个方向的保护(保护第 3 方网站免受 iframe 内容的影响)。

• 使用包含跨源 iframe 的网络组件可能会奏效。但是，为什么要通过包含 a) 脚本和 b) 网络组件标签来打扰嵌入的第 3 方网站呢？我看不出(在我的用例中)比简单地使用跨源 iframe 有什么真正的好处。

• 另一端的点击劫持弹窗补救措施是必须的。

这个问答由“在制定详细计划之前首先尝试了解您的工具”委员会赞助。