如果所有憑證都存儲在客戶端上，REST身份驗證如何安全處理？

Question

我閱讀有關API的最佳實踐此文檔

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

我已經建立了簡單的自定義之前的REST API，我覺得我已經成功地保護他們。之前，我在服務器上生成了客戶端的身份驗證「令牌」或護照，並將其打印在頁面上。這個想法是，客戶端既不能猜測也不能輕易地反向設計該令牌的生成方式，因爲生成它的函數對客戶端來說是不可見的。這是糟糕的用戶體驗，因爲令牌會在一段時間後過期，導致頁面過期並無法向API發出新請求。

但是，我仍然不確定在服務器與服務器「輕微分離」的情況下，這種情況會如何發生，因爲Web服務器沒有爲每個請求提供頁面。所以客戶需要事先了解一些關於認證的知識。

我覺得這種模式會迫使我在客戶端生成或存儲API認證細節，任何人都可以看到。我發現這種做法是不安全的，我想避免這種做法，但鑑於我知道的信息（我承認這種信息很稀疏），這是不可能的。

我在API安全性和身份驗證方面缺少這種模式？

Answer 1

您使用OAuth標記了您的問題，但您未提及此問題並將問題保持較寬泛。所以我覺得適當的通過顯示您保存驗證會話的客戶端，而在同一時間，不同的技術實施安全的一個很好的例子討論的概念，即JSON Web Token (JWT)

的基本流程如下：

1. 服務器上的客戶端的土地和提供其證書
2. 服務器將驗證憑據，構建了JWT令牌，並將其注入到HTTP頭
3. 客戶端將自動使用該HTTP報頭爲：每後續請求
4. 服務器驗證令牌，如果驗證是確定的，提供了資源

整個過程的關鍵點是令牌結構及其產生。基本上，令牌持有客戶端的身份驗證狀態。例如，它可能包含客戶的角色。

在這裏，主要關心的是防止客戶端僞造虛假標記。確保完整性的技術已經存在了很久，它被稱爲HMAC。基本上，由服務器注入的JWT如下

header : payload : HMAC[header,payload,secret] 

HMAC是隻能由知道祕密的實體來生成密碼散列是建立。所以，我們來玩一個攻擊場景。

1. 服務器上的客戶端的土地，並提出其證書

2. 服務器驗證憑據，並構建了JWT令牌這樣

   header : { "alg": "HS256", "typ": "JWT" } { "sub": "1234567890", "name": "John Doe", "admin": false <--- original role } HS256{...}

3. 客戶端嘗試篡改消息如下：

   header : { "alg": "HS256", "typ": "JWT" } { "sub": "1234567890", "name": "John Doe", "admin": true <--- tampered role } HS256{...}

但它不知道祕密，所以它不能計算正確的HS256代碼。

1. 服務器接收客戶端發送的頭部和篡改的有效負載，重新計算HMAC並將其與請求中發送的HMAC進行比較。它們不匹配，因此客戶會話已被更改。遊戲結束。

這是讓客戶端存儲會話，同時強制執行安全性的一種非常有趣的方式。