身份認證系統（一）單WEB應用的身份認證

身份認證技術，也就是所謂的登陸功能，是現代WEB系統最多見的功能之一。本系列文章就試圖爲你們詳細的介紹身份認證技術。

Basic認證模式

Basic認證模式是較早被普遍應用的一種HTTP標準提供的認證模式。最多見的形式之一就是在url中直接寫上用戶名密碼向服務器提供身份：

http://user:passwd@www.server.com/index.html

在Basic模式之中，每次向服務器請求受保護資源的時候都要在url中帶上明文或僅被Base64編碼過的用戶名密碼。並且在這種模式下，若是咱們要實現「記住登陸狀態」功能，就須要將用戶名密碼這樣的敏感信息直接換存在瀏覽器中。這樣就造成了它最主要的兩個缺點：

一、每一個請求中都要帶有用戶名和密碼憑據

二、安全性堪憂

基於session的認證模式

爲了解決每次請求敏感資源都要帶有用戶名密碼憑證的問題，web開發者們造成了一套基本的實踐模式，就是將用戶認證後的身份存儲於服務端管理的會話（session）之中，以此來減小使用過程當中對憑據的傳輸。

用戶想要請求受保護資源，先要登陸，想服務端發送用戶名密碼。服務端驗證用戶名密碼成功以後將用戶的身份驗證標識存儲在session 中，而後將sessionId存儲在cookie 中。以後當客戶再去請求受保護資源的時候，只要攜帶好cookie中的sessionId就能夠驗證其身份返回敏感數據了。

這種基於session的認證模式猶豫其簡單、方便、好用，因此被普遍使用。可是隨着web應用的發展，其也出現了諸多不足：

一、當服務器應用重啓時，用戶會被強制登出

二、當站點用負載均衡部署多份時，每一個站點實例的session沒法共享

固然，咱們可使用單獨的session存儲服務來解決這些問題，但這樣會增長系統不小的複雜性與維護成本。

基於cookie的認證模式

既然使用session會產生諸多的問題，那咱們是否是能夠有一種相似的方案來解決這種問題呢？答案確定是有的，那就是將認證信息直接存儲在客戶端的cookie中。

可是存在客戶端就會面臨着一系列的安全問題，例如，我直接在cookie中以用戶id存儲標識，那是否是用戶本身篡改cookie改稱別的用戶id就能夠切換本身的身份了呢？所以這就要涉及到cookie信息加密和解密。

除了加密與解密之外還有如今經常使用的一種解決方案：就是存儲票據（ticket）。在用戶登陸成功以後，站點生成一個ticket，一方面將用戶身份信息存儲在服務端緩存中，以ticket爲key；另外一方面，將ticket存儲到用戶的cookie中。這樣，用戶再要訪問敏感信息時，只須要每次都帶上本身cookie中的ticket就能夠了。這種方法其實和使用session很像，可是由於如今基本上緩存服務已經屬於必備的基礎組建了，因此並不會增長過多額外的成本，並且緩存服務相比session也比較好作長時間的數據存儲。

 

 

 

轉：https://www.cnblogs.com/meibaorui/p/9171878.html