请考虑以下情形。
网站foo.com有一个应用程序商店。开发人员可以登记有他们的应用程序。一个应用程序包括ID，标识，URL和一组权限的。
用户可以浏览App Store和激活应用程序。通过激活该应用程序，他们要接受的是，应用程序可以代表他们的行动给定的权限。激活的应用程序，让他们在与应用程序标识/ ID菜单的图标。它还生成并保存与所述权限的身份验证令牌。
当他们点击该应用相应的应用程序网址加载iframe中。到现在为止还挺好。现在，应用程序需要一种方式来真正代表对foo.com的用户的行为。为了实现这一目标的父窗口使用window.postMessage到身份验证令牌发送到包含应用程序的iframe。
在程序URL的html将不得不包括JS的一个小片断侦听来自父窗口的身份验证令牌。一旦它获得令牌可以在Cookie /会话存储/不管，并继续呈现应用程序，让代表用户的通话将其保存。
（注：我没有指定的身份验证令牌它可以是一个OAuth访问令牌或JWT或什么的。）
现在的问题：如何这是一个可怕和令人难以置信的不安全的想法？
另一种选择“标准”的做法是对应用程序的URL来启动3条腿OAuth认证方案，这将用户重定向回foo.com（在iframe里面，所以现在foo.com内foo.com）接受应用程序（这诚然，你可以自动完成，因为用户已经接受该应用程序），然后foo.com会回到应用程序的URL与授权代码，它可以换取一个访问令牌重定向。
我想建议的postMessage流程更简单和更清洁。什么缺点还是看不到？
显然，这是没有灵丹妙药第三方app标识。它只能在授权服务器控制第三方应用程序的加载情况。
如果身份验证令牌是JavaScript的访问，那么他们很容易受到XSS攻击。这就是为什么权威性饼干具有防止JS从他们的互动中HTTPOnly标志。
在第三方应用程序的XSS攻击可以揭示该特定第三方应用程序的应用程序的身份验证令牌。
在foo.com XSS攻击可以揭示所有的应用程序身份验证令牌。
标准三足式OAuth流与第三方后端发出的东西，其验证的浏览器作为各自的OAuth认证，浏览器结束。如果这是一个仅Http Cookie，则它更安全，因为它不容易受到XSS攻击。
另外，即使XSS风险是可以接受的，你仍然有CORS问题，因为浏览器会在第三方域发出请求foo.com