使用 Window.postMessage 将授权令牌发送到嵌入式应用程序
Use of Window.postMessage to send auth tokens to embedded apps
考虑以下场景。
网站 foo.com 有一个应用程序商店。开发人员可以在那里注册他们的应用程序。一个应用程序由一个 ID、徽标、url 和一组权限组成。
用户可以浏览应用商店并激活应用。通过激活该应用程序，他们接受该应用程序可以使用给定的权限代表他们行事。激活一个应用程序会在他们的菜单中为他们提供一个带有该应用程序的图标 logo/id。它还会生成并保存具有所述权限的身份验证令牌。
当他们点击该应用程序时，相应的应用程序 url 会加载到 iframe 中。到目前为止，一切都很好。现在，该应用程序需要一种在 foo.com 上代表用户实际操作的方法。为此，父 window 使用 window.postMessage 将身份验证令牌发送到包含应用程序的 iframe。
应用 url 中的 html 必须包含一小段 JS，用于侦听来自父 window 的身份验证令牌。一旦获得令牌，它就可以将其保存在 cookie/会话存储/其他任何地方，然后继续呈现应用程序并代表用户进行调用。
（注意：我没有指定授权令牌。它可以是 oAuth 访问令牌或 JWT 或其他任何东西。）
现在的问题是：为什么这是一个可怕且令人难以置信的不安全想法？
另一种 "standard" 方法是让应用程序 url 启动三足 oAuth 身份验证方案，这会将用户重定向回 foo.com（在 iframe 内，因此现在 foo.com inside foo.com) 接受应用程序（诚然你可以自动完成，因为用户已经接受了应用程序），然后 foo.com 将重定向回应用程序 url 带有授权代码，它可以交换访问令牌。
我认为建议的 postMessage 流程更简单、更清晰。我没有看到哪些缺点？
显然这不是识别第 3 方应用程序的灵丹妙药。仅在授权服务器控制第三方应用程序加载的情况下有效。
如果 javascript 可以访问身份验证令牌，那么它们很容易受到 XSS 攻击。这就是为什么 auth cookie 有 httpOnly 标志，阻止 JS 与它们交互。
对第三方应用程序的 XSS 攻击可能会泄露该特定第 3 方应用程序的应用程序授权令牌。
对 foo.com 的 XSS 攻击可能会泄露所有应用程序授权令牌。
标准的 3 条腿 oAuth 流程以第 3 方后端向浏览器发出一些内容作为相应的 oAuth 凭据对浏览器进行身份验证结束。如果这是一个 httpOnly cookie，那么它更安全，因为它不易受到 XSS 攻击。
此外，即使 XSS 风险可以接受，您仍然会遇到 CORS 问题，因为浏览器会在第三方域中向 foo.com
发出请求
考虑以下场景。
网站 foo.com 有一个应用程序商店。开发人员可以在那里注册他们的应用程序。一个应用程序由一个 ID、徽标、url 和一组权限组成。
用户可以浏览应用商店并激活应用。通过激活该应用程序，他们接受该应用程序可以使用给定的权限代表他们行事。激活一个应用程序会在他们的菜单中为他们提供一个带有该应用程序的图标 logo/id。它还会生成并保存具有所述权限的身份验证令牌。
当他们点击该应用程序时，相应的应用程序 url 会加载到 iframe 中。到目前为止，一切都很好。现在，该应用程序需要一种在 foo.com 上代表用户实际操作的方法。为此，父 window 使用 window.postMessage 将身份验证令牌发送到包含应用程序的 iframe。
应用 url 中的 html 必须包含一小段 JS，用于侦听来自父 window 的身份验证令牌。一旦获得令牌，它就可以将其保存在 cookie/会话存储/其他任何地方，然后继续呈现应用程序并代表用户进行调用。
（注意：我没有指定授权令牌。它可以是 oAuth 访问令牌或 JWT 或其他任何东西。）
现在的问题是：为什么这是一个可怕且令人难以置信的不安全想法？
另一种 "standard" 方法是让应用程序 url 启动三足 oAuth 身份验证方案，这会将用户重定向回 foo.com（在 iframe 内，因此现在 foo.com inside foo.com) 接受应用程序（诚然你可以自动完成，因为用户已经接受了应用程序），然后 foo.com 将重定向回应用程序 url 带有授权代码，它可以交换访问令牌。
我认为建议的 postMessage 流程更简单、更清晰。我没有看到哪些缺点？
显然这不是识别第 3 方应用程序的灵丹妙药。仅在授权服务器控制第三方应用程序加载的情况下有效。
如果 javascript 可以访问身份验证令牌，那么它们很容易受到 XSS 攻击。这就是为什么 auth cookie 有 httpOnly 标志，阻止 JS 与它们交互。
对第三方应用程序的 XSS 攻击可能会泄露该特定第 3 方应用程序的应用程序授权令牌。
对 foo.com 的 XSS 攻击可能会泄露所有应用程序授权令牌。
标准的 3 条腿 oAuth 流程以第 3 方后端向浏览器发出一些内容作为相应的 oAuth 凭据对浏览器进行身份验证结束。如果这是一个 httpOnly cookie，那么它更安全，因为它不易受到 XSS 攻击。
此外，即使 XSS 风险可以接受，您仍然会遇到 CORS 问题，因为浏览器会在第三方域中向 foo.com
发出请求