请考虑以下情形。
网站foo.com上有一个应用程序商店。开发人员可以在此注册他们的应用。一个应用程序由一个ID，徽标，URL和一组权限组成。
用户可以浏览应用商店并激活应用。通过激活该应用程序，他们接受该应用程序可以使用给定的权限代表他们执行操作。激活应用程序后，会在菜单中为他们提供带有应用程序徽标/标识的图标。它还会生成并保存具有所述权限的身份验证令牌。
点击应用后，相应的应用网址就会加载到iframe中。到目前为止，一切都很好。现在，该应用程序需要一种方法来代表用户在foo.com上实际采取行动。为此，父窗口使用window.postMessage将auth令牌发送到包含应用程序的iframe。
应用程序网址上的html必须包含一小段JS，以侦听来自父窗口的auth令牌。一旦获得令牌，它就可以将其保存在cookie /会话存储/任何内容中，并继续呈现应用并代表用户进行呼叫。
（注意：我没有指定auth令牌。它可以是oAuth访问令牌或JWT或其他任何东西。）
现在的问题是：这是一个多么可怕且令人难以置信的不安全主意？
替代的“标准”方法是让应用url启动3腿式oAuth身份验证方案，该方案会将用户重定向回foo.com（在iframe中，因此现在在foo.com中是foo.com）以接受该应用程序（由于用户已经接受了该应用程序，因此您可以自动执行此操作），然后foo.com将使用授权码重定向回该应用程序网址，它可以交换访问令牌。
我认为建议的postMessage流更简单，更简洁。我看不到什么缺点？
很明显，这不是识别第三方应用程序的灵丹妙药。仅在授权服务器控制第三方应用程序的加载的情况下才有效。
答案 0 :(得分：0)
如果auth令牌可被javascript访问，则它们容易受到XSS攻击。这就是为什么auth cookie具有httpOnly标志，以防止JS与之交互的原因。
对第三方应用程序的XSS攻击可能会泄露该特定第三方应用程序的应用程序身份验证令牌。
对foo.com的XSS攻击可能会泄露所有应用程序身份验证令牌。
标准的三足式oAuth流程以第三方后端向浏览器发出的内容结束，该内容将浏览器认证为相应的oAuth凭据。如果这是httpOnly cookie，则它更安全，因为它不易受到XSS攻击。
而且，即使XSS风险可以接受，您仍然会遇到CORS问题，因为浏览器将在第三方域向foo.com发出请求