對於Web應用程序，OAuth 2.0規範要求某種存儲本地存儲（「MUST ...」）作爲防範跨站請求僞造（CSRF）的一部分。該規範建議特別提供Cookie或HTML5本地存儲空間，並且隨着您的觀察結果顯示，Cookie是一種流行的實施方式。
引用RFC 6749 - The OAuth 2.0 Authorization Framework我們發現（加上強調）：
安全考慮
作爲一個靈活的，可擴展的框架，OAuth的安全 因素取決於很多因素。以下章節 爲實施人員提供了安全指導原則，重點介紹了第2.1節：Web應用程序， 基於用戶代理的應用程序和本機應用程序中描述的三個 客戶端配置文件。
...
10.12。跨站請求僞造
跨站請求僞造（CSRF）是一種利用在其中 使受害者終端用戶的用戶代理攻擊者遵循惡意URI （例如，提供給所述用戶代理作爲誤導性鏈接，圖像或重定向）發送到信任服務器（通常通過有效會話cookie的存在建立）。
針對客戶端的重定向
CSRF攻擊URI允許攻擊者 注入自己的授權碼或訪問令牌，該令牌可 結果在客戶端使用與 攻擊者的受保護的資源，而不是受害者的相關聯的訪問令牌（如，將受害者的銀行賬戶信息保存到受保護資源 ，受攻擊者控制）。
客戶端必須爲其重定向URI實現CSRF保護。 這通常通過要求發送到重定向URI端點的任何請求包括將請求綁定到用戶代理的經認證狀態（例如用於認證用戶代理的會話 cookie的散列）的值來實現）。當發出授權請求時，客戶端應該使用「狀態」請求參數將該值傳送給授權服務器 。
一旦授權被從最終用戶所獲得，所述 授權服務器重定向最終用戶的用戶代理返回到客戶端 與包含在「狀態」 參數所需的結合值。通過綁定值，客戶端可以通過將綁定值與 用戶代理的身份驗證狀態進行匹配來驗證請求的有效性。 用於CSRF 保護的綁定值必須包含一個不可猜測的值（如 第10.10節所述），並且用戶代理的身份驗證狀態（例如， 會話cookie，HTML5本地存儲）務必保存在 僅可由客戶端和用戶代理訪問（即受到 同源策略的保護）。
Mac上的Chrome與G +有同樣的問題。我也找不到任何澄清事情發生的文章或資料。 –
我找不到任何直接證實這個假設，但我懷疑網站通過在後端服務器端執行OAuth解決此問題，然後發送302 /重定向到客戶端，並直接從他們自己的域設置cookie。我懷疑是否嘗試執行OAuth客戶端會在Chrome中阻止第三方Cookie時始終失敗。 –