使用Window.postMessage將身份驗證令牌發送到嵌入式應用

Question

請考慮以下情形。

網站foo.com上有一個應用程序商店。 開發人員可以在此注冊他們的應用。 一個應用程序由一個ID，徽標，URL和一組權限組成。

用戶可以瀏覽應用商店並激活應用。 通過激活該應用程序，他們接受該應用程序可以使用給定的權限代表他們執行操作。 激活應用程序后，會在菜單中為他們提供帶有應用程序徽標/標識的圖標。 它還會生成並保存具有所述權限的身份驗證令牌。

當他們單擊應用程序時，相應的應用程序網址會加載到iframe中。 到現在為止還挺好。 現在，該應用程序需要一種方法來代表用戶在foo.com上實際采取行動。 為此，父窗口使用window.postMessage將auth令牌發送到包含應用程序的iframe。

應用網址上的html必須包含一小段JS，以偵聽父窗口中的auth令牌。 一旦獲得令牌，它就可以將其保存在cookie /會話存儲/任何內容中，並繼續呈現應用程序並代表用戶進行調用。

（注意：我沒有指定auth令牌。它可以是oAuth訪問令牌或JWT或其他任何東西。）

現在的問題是：這是一個多么可怕且令人難以置信的不安全想法？

另一種“標准”方法是讓應用程序網址啟動3腿式oAuth身份驗證方案，該方案將使用戶重定向回foo.com（在iframe中，因此現在在foo.com中是foo.com）以接受該應用程序（由於用戶已經接受了該應用程序，因此您可以自動執行此操作），然后foo.com將使用授權碼重定向回該應用程序網址，它可以交換訪問令牌。

我認為建議的postMessage流更簡單，更簡潔。 我看不到什么缺點？

顯然，這不是識別第三方應用程序的靈丹妙葯。 僅在授權服務器控制第三方應用程序的加載的情況下才有效。

Answer 1

如果auth令牌可被javascript訪問，則它們容易受到XSS攻擊。 這就是為什么auth cookie具有httpOnly標志，以防止JS與之交互的原因。

對第三方應用程序的XSS攻擊可能會泄露該特定第三方應用程序的應用程序身份驗證令牌。

對foo.com的XSS攻擊可能會泄露所有應用程序身份驗證令牌。

標准的三足式oAuth流程以第三方后端向瀏覽器發出內容的方式結束，該后端將瀏覽器作為相應的oAuth憑據進行身份驗證。 如果這是httpOnly cookie，則它更安全，因為它不易受到XSS攻擊。

同樣，即使X​​SS風險可以接受，您仍然會遇到CORS問題，因為瀏覽器將在第三方域向foo.com發出請求