## 2 身份認證 身份認證包含很多種，有HTTP Basic，HTTP Digest，API KEY，Oauth，JWK等方式，下面簡單講解下： ### 2.1 HTTP Basic REST由于是無狀態的傳輸，所以每一次請求都得帶上身份認證信息，身份認證的方式，身份認證的方式有很多種，第一種便是http basic，這種方式在客戶端要求簡單，在服務端實現也非常簡單，只需簡單配置apache等web服務器即可實現，所以對于簡單的服務來說還是挺方便的。但是這種方式安全性較低，就是簡單的將用戶名和密碼base64編碼放到header中。 ~~~ base64編碼前：Basic admin:admin base64編碼后：Basic YWRtaW46YWRtaW4= 放到Header中：Authorization: Basic YWRtaW46YWRtaW4= ~~~ 正是因為是簡單的base64編碼存儲，切記切記在這種方式下一定得注意使用ssl，不然就是裸奔了。 在某些產品中也是基于這種類似方式，只是沒有使用apache的basic機制，而是自己寫了認證框架，原理還是一樣的，在一次請求中base64解碼Authorization字段，再和認證信息做校驗。很顯然這種方式有問題，認證信息相當于明文傳輸，另外也沒有防暴力破解功能。 ### 2.2 API KEY API Key就是經過用戶身份認證之后服務端給客戶端分配一個API Key，類似：http://example.com/api?key=dfkaj134,一般的處理流程如下： 一個簡單的設計示例如下： client端： server端：  client端向服務端注冊，服務端給客戶端發送響應的api_key以及security_key，注意保存不要泄露，然后客戶端根據api_key,secrity_key,timestrap,rest_uri采用hmacsha256算法得到一個hash值sign，構造途中的url發送給服務端。 服務端收到該請求后，首先驗證api_key,是否存在，存在則獲取該api_key的security_key，接著驗證timestrap是否超過時間限制，可依據系統成而定，這樣就防止了部分重放攻擊，途中的rest_api是從url獲取的為/rest/v1/interface/eth0,最后計算sign值，完之后和url中的sign值做校驗。這樣的設計就防止了數據被篡改。 通過這種API Key的設計方式加了時間戳防止了部分重放，加了校驗，防止了數據被篡改，同時避免了傳輸用戶名和密碼，當然了也會有一定的開銷。 ### 2.3 Oauth1.0a或者Oauth2 OAuth協議適用于為外部應用授權訪問本站資源的情況。其中的加密機制與HTTP Digest身份認證相比，安全性更高。使用和配置都比較復雜，這里就不涉及了。 ### 2.4 JWT JWT 是JSON Web Token，用于發送可通過數字簽名和認證的東西，它包含一個緊湊的，URL安全的JSON對象，服務端可通過解析該值來驗證是否有操作權限，是否過期等安全性檢查。由于其緊湊的特點，可放在url中或者 HTTP Authorization頭中，具體的算法就如下圖