身份認證技術，也就是所謂的登錄功能，是現代WEB系統最常見的功能之一。本系列文章就試圖為大家詳細的介紹身份認證技術。
Basic認證模式
Basic認證模式是較早被廣泛應用的一種HTTP標准提供的認證模式。最常見的形式之一就是在url中直接寫上用戶名密碼向服務器提供身份：
http://user:passwd@www.server.com/index.html
在Basic模式之中，每次向服務器請求受保護資源的時候都要在url中帶上明文或僅被Base64編碼過的用戶名密碼。而且在這種模式下，如果我們要實現“記住登錄狀態”功能，就需要將用戶名密碼這樣的敏感信息直接換存在瀏覽器中。這樣就形成了它最主要的兩個缺點：
1、每個請求中都要帶有用戶名和密碼憑據
2、安全性堪憂
基於session的認證模式
為了解決每次請求敏感資源都要帶有用戶名密碼憑證的問題，web開發者們形成了一套基本的實踐模式，就是將用戶認證后的身份存儲於服務端管理的會話（session）之中，以此來減少使用過程中對憑據的傳輸。
用戶想要請求受保護資源，先要登錄，想服務端發送用戶名密碼。服務端驗證用戶名密碼成功之后將用戶的身份驗證標識存儲在session 中，然后將sessionId存儲在cookie 中。之后當客戶再去請求受保護資源的時候，只要攜帶好cookie中的sessionId就可以驗證其身份返回敏感數據了。
這種基於session的認證模式猶豫其簡單、方便、好用，所以被廣泛使用。但是隨着web應用的發展，其也出現了諸多不足：
1、當服務器應用重啟時，用戶會被強制登出
2、當站點用負載均衡部署多份時，每個站點實例的session無法共享
當然，我們可以使用單獨的session存儲服務來解決這些問題，但這樣會增加系統不小的復雜性與維護成本。
基於cookie的認證模式
既然使用session會產生諸多的問題，那我們是不是可以有一種類似的方案來解決這種問題呢？答案肯定是有的，那就是將認證信息直接存儲在客戶端的cookie中。
但是存在客戶端就會面臨着一系列的安全問題，例如，我直接在cookie中以用戶id存儲標識，那是不是用戶自己篡改cookie改稱別的用戶id就可以切換自己的身份了呢？因此這就要涉及到cookie信息加密和解密。
除了加密與解密以外還有現在常用的一種解決方案：就是存儲票據（ticket）。在用戶登錄成功之后，站點生成一個ticket，一方面將用戶身份信息存儲在服務端緩存中，以ticket為key；另一方面，將ticket存儲到用戶的cookie中。這樣，用戶再要訪問敏感信息時，只需要每次都帶上自己cookie中的ticket就可以了。這種方法其實和使用session很像，但是因為現在基本上緩存服務已經屬於必備的基礎組建了，所以並不會增加過多額外的成本，而且緩存服務相比session也比較好做長時間的數據存儲。