參考
傳統方案：jwt實現：1) 儲存到session（結合redis快取）
瀏覽器儲存sessesid,伺服器集群，
資訊存在在後台統一的session伺服器
沒有分布式架構，無法支援橫向擴充套件
2) 儲存到cookie
將驗證資訊儲存在資料庫中，後端每次都需要根據token查出使用者id，
這就增加了資料庫的查詢和儲存開銷。若把驗證資訊儲存在session中，
又加大了伺服器端的儲存壓力。
本質：儲存資訊在服務端
3）jwt
如果我們生成token遵循一定的規律，比如我們使用對稱加密演算法來加密
使用者id形成token，那麼服務端以後其實只要解密該token就可以知道使用者的id
jwt中使用對應演算法對使用者資訊加密。
jwt的目的
在伺服器身份驗證之後，將生成乙個json物件並將其傳送回使用者結構由三部分組成······
客戶在請求中發回json物件。伺服器僅依賴於這個json物件來標識使用者。
為了防止使用者篡改資料，伺服器將在生成物件時新增簽名
1） jwt頭：它會使用 base64 編碼組成 jwt 結構的第一部分,
2） jwt的主體：
乙個json物件
iss（簽發者）
exp（過期時間）
sub（面向的使用者）
aud（接收方）
iat（簽發時間）
它會使用 base64 編碼組成 jwt 結構的第二部分
3） 簽名雜湊：
signature 需要使用編碼後的 header 和 payload 以及我們提供的乙個金鑰，
然後使 用 header 中指定的簽名演算法（hs256）進行簽名。
簽名的作用是保證 jwt 沒有被篡改過
三個部分組合成乙個字串，每個部分用"."分隔，就構成整個jwt物件
缺點：一旦jwt簽發，在有效期內將會一直有效
jwt的有效期不宜設定太長。對於某些重要操作，
使用者在使用時應該每次都進行進行身份驗證或手機驗證碼。
盡量使用 https
cas:在請求cas client 時使用者必須帶有cas server第三方授權機制帶你區分清楚authentication,authorization以及cookie、session、token生成的service ticket
流程：1、使用者訪問cas client
2、重定向到cas server為驗證成功(儲存登入資訊)使用者生成service ticket
3、將service ticket傳遞cas client、
4、cas client向service ticket發起驗證，成功返回user info
單點登入的三種方式
單點登入sso single sign on 說得簡單點就是在乙個多系統共存的環境下，使用者在一處登入後，就不用在其他系統中登入，也就是使用者的一次登入能得到其他所有系統的信任。單點登入在大型 裡使用得非常頻繁，例如像阿里巴巴這樣的 在 的背後是成百上千的子系統，使用者一次操作或交易可能涉及到幾十個...
單點登入的三種實現方式
宣告 此文 自jc huang 單點登入sso single sign on 說得簡單點就是在乙個多系統共存的環境下，使用者在一處登入後，就不用在其他系統中登入，也就是使用者的一次登入能得到其他所有系統的信任。單點登入在大型 裡使用得非常頻繁，例如像阿里巴巴這樣的 在 的背後是成百上千的子系統，使用...
單點登入的三種實現方式
cookie 的作用域由 domain 屬性和 path 屬性共同決定。domain 屬性的有效值為當前域或其父域的網域名稱 ip位址，在 tomcat 中，domain 屬性預設為當前域的網域名稱 ip位址。path 屬性的有效值是以 開頭的路徑，在 tomcat 中，path 屬性預設為當前 w...