前言：
在互聯網發展的初期，Web基本上只是內容的瀏覽而已，服務器不需要記住每個請求的狀態，也就是說每一次客戶請求都是一次新的請求，這也就是http無狀態的一個表現。隨着互聯網時代的到來，尤其是購物網站的興起，系統需要辨識出用戶信息。解決辦法就是在客戶端請求的時候攜帶一種標識，這中標識就代表不同的用戶，這樣服務器就能區別出不同的用戶了。這就誕生了用戶認證的這個概念。
用戶認證：簡而言之就是驗證一個用戶是不是合法用戶的處理過程
有一點需要記住，認證和授權不是一回事。是兩個不同的階段。大部分系統都是先對用戶進行驗證在進行授權。舉例，
普通用戶和管理員同時登錄一個網站，出現的界面是不同的，那麼登錄的過程就是驗證，出現不同的頁面就是授權的具體表現。
1 session認證
session：在網絡應用中被稱爲"會話控制"。session對象儲存特定用戶會話所需要的屬性和配置信息。這樣用戶在頁面跳轉的時候 儲存 session對象中的變量就不會丟失，而是在整個用戶會話中一直存儲下去。如果用戶還沒有會話 web服務器會自動創建一個session對話，當對話過期或或者被放棄後，服務器就會終止該對話。
基於session認證方式的最主要的一個特點就是 服務器端存儲這用戶信息，客戶端是通過攜帶一個sessionid的cookie來做session表示的。很多項目都喜歡用session認證的方式，這種方式對於快速開發上線項目極爲有利。每個客戶端需要保存一個cookie，但是服務器端卻需要保存成千上萬的session信息，這無疑是對服務器端造成了很大的壓力，尤其是當做了負載均衡之後。session的命中問題更爲可怕。舉一個例子；用戶A登錄系統成功，服務器A下發sessionid，session信息存儲在服務器A上，如果當下次請求到服務器B上的時候，由於服務器B上沒有session信息，所以就造成了未命中的現象，這也就是session認證解決方贊實施過程面臨的一個問題，解決辦法就是 其中一個便是 session複製 ，服務端的每一個服務器都存儲一個session的副本，這樣請求不論到那個服務器都可以訪問到session信息了。但是這樣就增加了服務器的存儲壓力，還會出現複製延遲，session更新同步 過期同步等問題。
解決問題就是利用第三方進行集中存儲 redis，memcached把sessio信息都存儲在同一個地方，所有的服務器都訪問這個地方，
引入第三方就存在第三方掛到的可能性，所以現在都基本採用第三方集羣的方案來減小這種可能性。大多數session機制是基於cookie的。在一定程度上session的 io操作話費的時間有的時候也是很大的，
cookie 驗證
把用戶信息都放在客戶端，麼了服務器存儲的壓力。
服務器處於無狀態的形式，所以可以很方便的橫向擴展。
基於cookie的認證方式也有很多缺點。
1 cookie 是存儲在客戶端的，所以在一定程度上增加可以僞造的機率，安全性稍微弱一點。
2 由於cookie在瀏覽器有跨域的阻攔，所以在有跨域需要的時候，需要服務器做相應的配置，
3 cookie 是有長度的限制的，所以不宜存儲過長的信息。
4 用戶的客戶端可能會禁用cookie，這個時候可以依靠url傳值來解決問題。
5 服務器端想要操作cookie認證信息的失效比較困難，不像session認證那樣方便。
最後；
無論是session 還是cookie認證，都是需要客戶端上傳標識，都需要服務器下發標識，並且對這個標識進行加密，標識裏最好加上來源ip過期時間這個屬性。在配上https 可以更加有效的保護整個認證流程和數據。也許還有很多更好的認證方式。