自定義安全HTTP標頭是否違反了關注點分離

Question

自定義應用程序特定的與安全性相關的HTTP標頭是否違反了關注點分離，這是否被認爲是不好的做法？我意識到使用自定義頭來控制服務將緊密夫婦客戶端與服務實施。或者在這種情況下，控制安全框架的行爲。在這裏我準備用這些自定義標題的背景是這樣的：

我們使用基於令牌的認證，其中token有固定的壽命，並且新的令牌每次發出驗證的客戶端調用Web API。 SPA客戶端可以調用與AJAX服務器，兩種環境下

• 用戶操作（導航和提交）
• 自動刷新（當前視圖以固定間隔重新獲取數據）現在

，如果用戶當頁面打開時，會話永不過期，因爲每個自動獲取都會生成新的令牌。 不知何故，我們需要將用戶操作與服務器端的自動刷新區分開來，並且僅針對用戶操作發出新令牌。

我實現基於WebSocket的刷新將是一個解決方案，但我們決定堅持定時AJAX調用由於具體事宜。另一種解決方案是將令牌刷新作爲單獨的端點提供，但這會違反客戶的DRY原則，並且使用Spring Security進行設置會更麻煩。

唯一剩下的選擇是將用戶/自動信息嵌入到請求本身中，並且使用標頭似乎是一個可行的選項。某個標題的存在會阻止令牌刷新。易於使用幾行代碼實現。

我只關心，如果夫妻的客戶太多與服務實現。從技術上講，它不會將客戶端與服務耦合，而是前面的安全過濾器，從而泄漏用戶界面中的安全問題。理想的安全措施對用戶界面應該是透明的，所以新的客戶端可以在不知道安全性的情況下進行編碼（特別是在使用cookie的情況下）。

另一方面，此解決方案不具有破壞性或變化性。這是一個可選功能。通過客戶端使用它，安全性得到增強，但在任何情況下都不會降低（從服務器的角度來看，就像它一樣）。現在的問題是，使用可選標題來增強安全性的原則是違反的，在這種情況下它是一個有效的解決方案嗎？

在我的選擇的安全性應透明最大化，但我不明白怎麼就不能在這種情況下泄露在客戶端的安全問題。

Answer 1

這聽起來像你在這裏使用自己的自制的自定義令牌驗證解決方案。這不是一個好主意。

我會花點時間來解釋爲什麼你不想做你提出什麼，然後更好的選擇是什麼。

第一關 - 你試圖在這裏解決的問題是，你不想讓用戶保持登錄到您的網站永遠如果他們離開一個標籤頁中打開。你需要解決這個問題的原因是，現在，你正在爲用戶分配一個新的訪問令牌（EVERY REQUEST）。

處理上述問題的正確解決方案是有兩種類型的令牌。

一個擁有很短使用期限（假設：1小時）的訪問令牌和一個具有較長使用期限（假設：24小時）的刷新令牌。

方式這應該工作是：

• 當用戶第一次驗證爲您服務，訪問和刷新標記與它們各自的超時產生。
• 這些標記都設置在客戶端JS無法訪問的HTTP cookie中。
• 從這一刻起，每當用戶的瀏覽器向您的服務發出請求時，您都會從Cookie中解析出Access令牌，檢查它是否有效，然後允許請求。
• 如果訪問令牌不再有效（如果它已過期），則會從Cookie中解析出Refresh令牌，並查看該令牌是否有效。
• 如果刷新令牌有效，您將生成一個帶有另一個1小時生命週期的NEW Access令牌，並使用新的開啓覆蓋舊的Access令牌cookie。
• 如果刷新令牌無效，您只需將301重定向返回到應用的登錄頁面，強制用戶再次手動重新進行身份驗證。

這種流動有許多好處：

• 有一個最大會話長度，這是技術（訪問令牌的刷新令牌+持續時間的持續時間） - 又名：在這個例子中25小時。
• 訪問令牌是短暫的，這意味着如果令牌受到某種程度的破壞，攻擊者不能長時間使用它來冒充用戶。

上述流程的好處在於它是一個網絡授權標準：OAuth2。

OAuth2密碼授權流程完全符合您所描述的內容。它生成兩種類型的令牌，處理「令人耳目一新的令牌」，以安全，符合標準的方式從頭到尾處理整個事件。

我強烈建議你做的是在你的服務器和客戶端上實現一個OAuth2庫，這將爲你處理這些需求。

現在 - 關於令牌，現在大多數OAuth2實現都會生成令牌JSON Web Tokens。這些是具有加密簽名的令牌，可提供多種安全優勢。無論如何：我希望這是有幫助的！我使用Python，Node和Go編寫了幾個流行的身份驗證庫 - 所以這是我在過去幾年中使用這些協議的直接經驗。