安全地將OAuth令牌與javascript客戶端進行通信

Question

我正在設計一個以REST API爲中心的多平臺應用程序（客戶端將包括內部開發的移動應用程序，以及最初的AJAX重javascript客戶端）。由於將來API可能面向第三方開放，因此我正在考慮使用OAuth 2.0進行API驗證和授權。

我想要解決一些與此安排有關的安全問題，特別是關於javascript客戶端。我不希望這個客戶端像第三方客戶端那樣行事，可能會有大量的重定向和彈出窗口以及大部分OAuth文檔似乎關注的內容。由於它將從我自己的域中交付，因此我認爲webapp的服務器端可以是實際的客戶端，並存儲客戶端機密和刷新標記，而javascript會根據需要從服務器中檢索新的認證令牌。

爲了把它在一步一步形式：

1. 用戶登錄使用非Ajax的HTML表單，生成AUTH和刷新其上存儲服務器側令牌。這設置了一個僅HTTP的登錄會話cookie。
2. JavaScript客戶端代碼在登錄後發送到用戶的瀏覽器。
3. javascript客戶端向屬於其自己的應用程序（不是REST API的一部分）的資源發出請求以檢索令牌。會話cookie確保客戶端是真實的，並且引用者也將被檢查。 Auth令牌返回。
4. javascript客戶端使用REST API驗證令牌。
5. 客戶端現在可以使用該令牌在REST API過期前發出請求。
6. 如果授權令牌到期或頁面關閉並重新打開，javascript客戶端可以請求新的令牌。只要登錄會話cookie仍然有效，webapp的服務器端負責刷新令牌併發送新令牌。

這是否有意義，還是會留下大量的漏洞？特別是，在網絡上有一個資源基於設置的cookie傳遞認證令牌是否瘋狂？

Answer 1

只要確保與瀏覽器的任何通信都是HTTPS，以便中間沒有人可以竊取您的令牌。並在您的身份驗證cookie上設置「安全」標誌。

• 現在的大多數瀏覽器授權方案歸結爲一個cookie中傳遞的會話標記。 OAuth 2方案提前幾步，因爲a）令牌（可以）是愚蠢的令牌，內部沒有危險的用戶信息，以及b）它們到期。

• （只是把在上下文評論：！有一次我從一個網站突然打開會話令牌，發現我家的地址和電話號碼在那裏確認）

• 我見過的代碼HMAC在瀏覽器javascript內部對請求進行簽名，但它帶有一個巨大的免責聲明：不要在生產中使用它。一個簽名方案要求客戶端（javascript）知道一個「祕密」字符串，但瀏覽器/ javascript是如此不安全，以至於等於將祕密字符串交給了世界。

但是，如果你把你所有的commuinication通過HTTPS，那麼你真的只是把上傳遞會話令牌餅乾熟悉方案的OAuth的扭曲。