此身份验证流程安全吗？

Question

目标

在 3rd 方网站上嵌入一个表单，该表单可以使用第一方身份验证（OIDC、keycloak）发布到受不记名令牌保护的第一方服务。 （想想类似于 à la disqus 的评论形式。）

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

关注点

1. 防止点击劫持

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

3. 将用户信息和令牌与 3rd 方网站隔离

方法

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

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

2. 根据传递列表检查 window.opener 和检查 window.opener（参见图片：登录登录）应确保登录登录未嵌入 iframe，未直接导航到，并且仅从授权网站的弹出窗口中访问。 检查 window.postmessage 命令的 targetOrigin 应该确保只有经过授权的网站才能成功使用该表单。

3. 让 Web 组件（参见图片：第一方 Web 组件）使用来自 srcDoc 的内部沙盒 iframe 来执行所有用户信息或令牌相关操作，应保护用户信息和令牌不被 3rd 方访问网站。使用内部 iframe 还要保证，使用 web 组件的 3rd 方网站无法拦截 postmessage 事件。

问题

1. 这种方法安全吗？

2. 对于这个我不知道的问题，有没有更标准化的方法？

感谢您的投入！

Answer 1

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

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

• 通过 srcdoc 填充的 iframe 显然不算作跨域框架。嗯，嗯。这意味着它不是针对第 3 方网站的可行保护措施。通过在其上添加沙箱属性并没有变得更好，因为这旨在提供另一个方向的保护（保护 3rd 方网站免受 iframe 内容的影响）。

• 使用包含跨域 iframe 的 Web 组件可能有效。但是为什么要在嵌入的 3rd 方网站中包含 a）脚本和 b）Web 组件标签呢？与简单地使用跨域 iframe 相比，我看不到真正的好处（在我的用例中）。

• 针对另一侧的点击劫持的弹出式补救措施是必须的。

此问题和答案由“在制定详细计划之前首先尝试了解您的工具”委员会发起。