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

Question

自定義應用程序特定的，與安全性相關的HTTP標頭是否違反關注點分離，是否被認為是不好的做法？ 我意識到使用自定義標頭控制服務將使客戶端與服務實現 緊密耦合 。 或者在這種情況下，要控制安全框架的行為。 我計划使用自定義標頭的上下文如下：

我們使用的是基於令牌的身份驗證，其中令牌具有固定的生存期，並且每次經過身份驗證的客戶端調用Web API都會發出新的令牌。 SPA客戶端可以在兩種情況下使用AJAX調用服務器

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

現在，如果用戶使頁面保持打開狀態，則會話將永不過期，因為將為每個自動提取生成新令牌。 某種程度上，我們需要將用戶操作與服務器端的自動刷新區分開來，並僅針對用戶操作發出新令牌 。

我意識到基於Websocket的刷新將是一種解決方案，但是由於特定的原因，我們決定堅持使用定時AJAX調用。 另一個解決方案是提供令牌刷新作為單獨的端點，但是從客戶端的角度來看這將違反DRY原則，並且使用Spring Security進行設置會更加麻煩。

剩下的唯一選擇是將用戶/自動信息嵌入請求本身，在這里使用標頭似乎是一個可行的選擇。 某些標頭的存在將阻止令牌刷新。 只需幾行代碼即可輕松實現。

我只擔心，如果這會使客戶端與服務實現之間的耦合過多。 從技術上講，它不將客戶端與服務耦合，而是將前面的安全過濾器耦合，從而泄漏用戶界面中的安全問題。 理想情況下，安全性對用戶界面應該是透明的，因此可以在不了解任何安全性的情況下對新客戶端進行編碼（尤其是在使用cookie時）。

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

在我的選擇中，應該透明地最大化安全性，但是在這種情況下，我看不出如何在客戶端中不泄漏安全性問題。

Answer 1

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

我將花一點時間解釋為什么您不想做您打算提出的事情，然后再說什么是更好的選擇。

首先-您要在此處解決的問題是，您不希望用戶在打開標簽頁后永遠保持登錄狀態。 您需要解決此問題的原因是因為現在，您正在根據用戶的“每個請求”分配一個新的訪問令牌。

解決上述問題的正確方法是使用兩種令牌。

具有很短壽命（例如：1小時）的訪問令牌和具有更長壽命（例如：24小時）的刷新令牌。

它應該工作的方式是：

• 當用戶首次對您的服務進行身份驗證時，將生成Access和Refresh令牌及其相應的超時。
• 這些令牌都設置在客戶端JS無法訪問的HTTP cookie中。
• 從現在開始，每次用戶的瀏覽器向您的服務發出請求時，您都會從Cookie中解析出訪問令牌，檢查其是否有效，然后允許該請求。
• 如果訪問令牌不再有效（如果它已過期），則將從cookie中解析出刷新令牌，並查看其是否有效。
• 如果刷新令牌有效，則將生成一個具有1小時壽命的NEW Access令牌，並使用新的on覆蓋舊的Access令牌cookie。
• 如果刷新令牌無效，則只需將301重定向返回到應用程序的登錄頁面，從而迫使用戶再次手動進行重新認證。

這種流程有很多好處：

• 最大會話長度是技術性的（刷新令牌的持續時間+訪問令牌的持續時間）-aka：在此示例中為25小時。
• 訪問令牌的壽命很短，這意味着如果令牌遭到某種程度的破壞，攻擊者就不能長時間使用它來冒充用戶。

上面的流程的好處是，它是一個Web授權標准： OAuth2 。

OAuth2密碼授予流程完全符合您的描述。 它生成兩種類型的令牌，處理“刷新”令牌，以安全，符合標准的方式從頭到尾處理整個事情。

我強烈建議您做的是在服務器和客戶端上都實現OAuth2庫，它將為您解決這些需求。

現在-關於令牌，當今大多數OAuth2實現都會將令牌生成為JSON Web令牌 。 這些是經過加密簽名的令牌，可提供許多安全優勢。

無論如何：我希望這會有所幫助！ 我用Python，Node和Go編寫了幾種流行的身份驗證庫-因此，這來自於我在過去幾年中使用這些協議的直接經驗。