從JWT令牌隱藏內部用戶標識

Question

有一個REST API服務正在開發中，它爲用戶提供了不同的內部SQL數據庫搜索方法，以提出請求。 數據庫包含多個表，每個表都有user_id列，它是用戶表（唯一整數，主鍵）中id列的引用鍵。這個很重要。

當用戶從客戶端應用程序登錄時，他獲取包含具有用戶標識值的「子」部分的JWT標記。 然後，當用戶調用某個API方法時，他只提供JWT令牌，所以API從「sub」獲取用戶ID，並向適當的表進行搜索請求。 因爲每個表都有user_id列，所以沒有必要在SQL查詢中的用戶表上進行聯接（如果我們不需要響應中的用戶信息）。

問題是暴露內部用戶ID是一個不好的做法，可能會導致安全/業務問題。 所以我正在尋找隱藏它。現在我看到如下選項：

• 更改用戶ID爲字符串列（使用順序GUID），但是這是我們的系統龐大重大更改

• 現存用戶表額外ext_user_id列（GUID），並在JWT令牌中使用此值。缺點在於，每個SQL查詢都會「加入」User表以獲取用戶標識值。

• 保持原樣，但使用JWE令牌代替JWT。缺點是每個API請求都會執行令牌解密，這可能會影響性能。

也許還有其他選擇嗎？或者其中一種方法比其他方法更有優勢（實際上除了第一種）？

Answer 1

基本上我認爲這些都是你的選擇。

您專注於性能。通過解決方案2和3，您必須比較SQL查詢/加入的開銷，以獲取用戶標識和JWE標記的解密。

JWE解密時間總是基本相同，對稱密鑰可能需要幾毫秒的處理器時間。但是，數據庫查詢需要磁盤訪問權限，並取決於其他因素：記錄數量，連接數量，磁盤訪問時間等。如果不詳細瞭解問題，則無法給出絕對度量。我建議你憑經驗測量每種情況下的開銷，並評估它是否是你

除了性能，我建議通過隱藏ID重視抵押問題一個問題：

請問您需要的客戶端知道您的REST API中的ID？

例如，如果您有使用這樣

/user/{userId}/getSomeData 

JWE的ID也不會有用的，因爲你需要以任何方式

你需要提供的標識符的資源客戶解碼智威湯遜？

如果使用JWE，客戶機不能解碼，因爲它不具備解密密鑰

有多少地方在你的服務器需要將GUID轉換爲ID？

您將需要爲每個查詢或在入口點的過濾器中的一般轉換查詢