首先我們要弄清楚普通的Http協議為什么要加入身份認證呢？ 因為Http協議是無狀態性的，你的每一次請求都是相對獨立的， 服務器需要知道你的用戶身份再決定你可以訪問什么樣的資源。
基本認證 HTTP Basic Authentication
這種方式最簡單，當請求某個資源時，服務器返回401。再次請求參數中需要攜帶用戶名和密碼，准確來說是用戶名和密碼組合后經過base64轉碼的一個字符串。優點是簡單，缺點也很明顯：base64很容易解碼，就代表請求被截取后用戶名密碼就會泄露。對於服務端來說，每次都需要驗證用戶名和密碼很不方便。
單獨的APIKey認證
這種方式可以說是方法1的延伸。既然用戶名和密碼比較麻煩，那么請求時就在頭信息中存儲一個用戶密鑰用於驗證身份，服務端有單獨的區域存儲密鑰。缺點是當請求被截獲后，密鑰也會被盜用。而且長時間使用同一密鑰更加的不安全。因為單一的密鑰不安全，很多開發人員就在頭信息（大部分是在Cookie中）添加多個字段，比如sessionid、uid、token。服務端通過驗證多個參數，確定用戶身份，如果session設置了一段時間后失效的機制，安全性就有了基本保障。
OAuth2.0
這種認證方式你可以理解為移動APP中的方式2。當用戶首次訪問是需要提供用戶名、密碼。服務端返回一個code。攜帶這個code請求認證服務器，認證服務器會返回給你一個會過期的密鑰，存儲在客戶端本地。你全程都在和認證服務器溝通，從而保證了主服務端的安全性。
數字簽名認證
前幾種方式，當請求被截取后用戶身份的相關字段都可以被獲取到。 如果在請求正文中添加一個參數sign，這個參數是頭信息中的密鑰加上請求體參數在某種算法的作用上生成的一個MD5字符串。第一MD5是很難破解回原始值的，第二攻擊者很難推算請求體參數和密鑰的組合算法。
總的來說，服務器如果驗證了密鑰和MD5字符串全部正確，就說明身份正確且參數在傳入過程中沒有被篡改。
現在很多技術團隊都選擇Http/Restful接口類型，這種方式的好處是輕量且開發快捷，但安全性方面需要加入補充提升。 如果你在公司測試這類接口，就要注意接口的安全性尤其是用戶身份認證的機制。