大家leader 可能都不知道的用戶鑑權機制的原理

互聯網年代，一個網站的用戶數，就是這個網站的命脈，那麼，這些用戶的帳戶安全問題很成問題，因而行業大佬們，開始憂國憂民，研究出不少解決當下痛點的解決方案。從最開始的先後端不分離，研究出來的session-cookie，到後來基於前端存儲的Token 驗證 ，後來網站愈來愈多多了，爲了避免老是註冊帳號推出來的OAuth權限，以及一個公司項目太多了，爲了防止重複登陸開啓的單點登陸。

到這裏你就會發現，咱們每一步的鑑權方案，其實就是一個前端的行業成長史，每一種方案，都在特定的歷史環境下，解決了一些痛點，而且在行業突飛猛進的狀況下，完成了歷史使命，而退出舞臺。

在我看來透徹的瞭解目前的前端鑑權方案，除了有利於咱們面試找工做。一樣的他能幫助你瞭解前端這個工種，是怎樣從一個簡單的切圖仔一步步成長爲工程師的。是有多少前輩在刀耕火種的年代，不畏艱難積累知識，瞭解過去。開枝散葉，無私奉獻，纔有了咱們今天的高薪。繁榮

因而，你開始滿懷敬畏，空杯心態，努力學習，樂於助人，積極進取 .........吧啦吧啦吧啦.......

以上內容純屬扯淡，就到這吧！下面開始正題，本文爲某最近整理前端鑑權機制的大體體系留下來的一些筆記，若有幫助請點贊，若有錯誤請指出，如已瞭然，請全當樂呵！

本文大致從時間線，以及解決何種問題，和大體底層原理來闡述前端鑑權的幾種經常使用方案。請各位看官批評！

session-cookie

首先登場的是session-cookie機制，這是出現時間最先，也是使用最多的鑑權方式（由於如今不少老系統還在維護）。

在正式開講以前咱們先了解一什麼叫cookie，什麼叫session， 爲啥要有這兩種產物

Session

咱們知道互聯網的興起離不開網絡，網絡就離不開協議，而在咱們前端中打交道的就是http協議，然而，他好死不死的是個無狀態協議，就是在傳輸過程當中不記錄先後端交互的一些狀態，在互聯網迅猛發展的過程當中，就有了用戶的概念，一個網站也不是純展現爲主，因而服務端須要記錄用戶的狀態時，就須要用某種機制來識具體的用戶，這個機制就是Session，上述內容可能還有夥伴不太明白，接下來舉個例子

典型的場景好比購物車，當你點擊下單按鈕時，因爲HTTP協議無狀態，因此並不知道是哪一個用戶操做的，因此服務端要爲特定的用戶建立了特定的Session，用於標識這個用戶，而且跟蹤用戶，這樣才知道購物車裏面有幾本書。這個Session是保存在服務端的，有一個惟一標識。

到這裏你就會發現其實Session就是一個信息，而且有一個惟一標識，來識別身份

cookie

剛纔說到，session是一個信息，這樣範圍就很廣了，他像是一個抽象的概念，而cookie 則是一個真實存在的東西，他是客戶端或者瀏覽器的一種技術，說白了就是一種存儲內容的技術，而且會在客戶端發起http請求的時候攜在http的header中。

ok 說完這二者以後咱們就應該明白了他們二者的區別和聯繫，接下來就來驗證一一下session-cookie 的鑑權機制究竟是怎麼樣的

如上圖所示，所謂session-cookie模式就是將服務器保存信息，生成一個惟一標識，而後下發給客戶端，保存在cookie中，這樣每次客戶端就能使用這個惟一標識去判斷用戶的一些狀態以及登陸信息，這就是session-cookie的原理。

其實本質很質樸，可是因爲互聯網的發展，只是簡單的生成一個惟一標識很容易被人破解，因而，又開始了折騰之路。

因爲最開始的簡單生成一個cookie，很容易被人模仿，和僞造，和篡改，這樣用戶信息就會泄露，因而，引入Hash算法，來驗證當前用戶身份，防止僞造。

hash算法

哈希（hash）算法又稱爲散列算法，經過hash算法，能夠將任意長度的信息轉換成一個固定長度的二進制數據，咱們常常會使用十六進制值來表示轉換後的信息。
複製代碼

基本原理就是把任意長度的輸入，經過Hash算法變成固定長度的輸出。這個映射的規則就是對應的Hash算法，而原始數據映射後的二進制串就是哈希值。活動開發中常用的MD5和SHA都是歷史悠久的Hash算法。

ok 說了這麼多，hash算法有什麼特色呢？

• 從hash值不能夠反向推導出原始的數據
• 輸入數據的微小變化會獲得徹底不一樣的hash值，相同的數據會獲得相同的值
• 哈希算法的執行效率要高效，長的文本也能快速地計算出哈希值
• hash算法的衝突機率要小

在密碼學中，hash算法的做用主要是用於消息摘要和簽名，換句話說，它主要用於對整個消息的完整性進行校驗。

舉個例子，咱們登錄掘金的時候都須要輸入密碼，那麼掘金若是明文保存這個密碼，那麼黑客就很容易竊取你們的密碼來登錄，特別不安全。因此，他就使用hash算法生成一個密碼的簽名，數據庫保存這個簽名值。因爲hash算法是不可逆的，那麼黑客即使獲得這個簽名，也絲毫沒有用處；由於他反推不出來這個密碼。而若是你在網站登錄界面上輸入你的密碼，那麼提交請求的時候從新計算一下這個hash值，與網站中儲存的原hash值進行比對，若是相同，證實你擁有這個帳戶的密碼，那麼就會容許你登錄。銀行也是如此，銀行是萬萬不敢保存用戶密碼的原文的，只會保存密碼的hash值而而已。

而在咱們的sessionId 中加入hash算法來生成簽名其實和密碼的這個例子相似，是爲了防止黑客拿到sessionid 可是因爲hash算法生成了一個簽名，那麼若是在訪問接口的時候不匹配，那麼就能夠判斷當前用戶是僞造的。

Token 驗證（jwt）

在瞭解完了cookie-session 原理以後，咱們發現cookie-session有着不少不足，這時大佬們有開始研究了。這就是後來的token 驗證，咱們先來看看cookie-session的不足

• 服務器有狀態，須要要保存全部人的session id ！ 若是訪問服務器多了， 就得由成千上萬，甚至幾十萬個，壓力山大
• 很是不靈活，若是APP沒有cookie並無辦法存儲，跨域狀況下在不作特殊處理的狀況下，cookie沒法傳遞

因而大名鼎鼎的tokne模式橫空出世，這也是當下全部企業級項目廣泛的鑑權方式,那麼他有什麼特色呢？

• 支持跨域訪問: Cookie是不容許垮域訪問的，token支持
• 無狀態： token無狀態，session有狀態的
• 去耦: 不須要綁定到一個特定的身份驗證方案。Token能夠在任何地方生成，只要在你的API被調用的時候， 你可 以進行Token生成調用便可
• 更適用於移動應用: Cookie不支持手機端訪問的
• 性能: 在網絡傳輸的過程當中，性能更好
• 基於標準化: 你的API能夠採用標準化的 JSON Web Token (JWT). 這個標準已經存在 多個後端庫（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如： Firebase,Google, Microsoft）

那麼他是怎麼工做的呢？

• 1. 客戶端使⽤用⽤用戶名跟密碼請求登陸
• 2. 服務端收到請求，去驗證⽤用戶名與密碼
• 3. 驗證成功後，服務端會簽發⼀一個令牌(Token)，再把這個 Token 發送給客戶端
• 4. 客戶端收到 Token 之後能夠把它存儲起來，⽐好比放在 Cookie ⾥裏里或者 Local Storage⾥裏里
• 5. 客戶端每次向服務端請求資源的時候須要帶着服務端簽發的 Token
• 6. 服務端收到請求，而後去驗證客戶端請求⾥裏里⾯面帶着的 Token，若是驗證成功，就向客戶端返回請求的數據token會有過時時間，客戶端登出的時候也會廢棄token，可是服務端不不須要任何操做

到目前爲止咱們先來對比一下Token與cookie-session的區別

• session要求服務端存儲信息，而且根據id可以檢索，⽽而token不不須要（由於信息就在token中，這樣實現了了服務端⽆無狀態化）。在⼤大規模系統中，對每一個請求都檢索會話信息多是⼀一個複雜和耗時的過程。但另外⼀一⽅方⾯面服務端要經過token來解析⽤用戶身份也須要定義好相應的協議（⽐好比JWT）。
• session⼀通常經過cookie來交互，⽽而token⽅方式更更加靈活，能夠是cookie，也能夠是header，也能夠放在請求的內容中。不不使⽤用cookie能夠帶來跨域上的便便利利性。
• token的⽣生成⽅方式更更加多樣化，能夠由第三⽅方模塊來提供。
• token若被盜⽤用，服務端⽆沒法感知，cookie信息存儲在⽤用戶⾃⼰電腦中，被盜⽤用⻛風險很是小。

明白了工做流程，咱來來一塊兒研究下原理，以前咱們說過token鑑權是有標準的好比jwt，那麼咱們就來解析jwt原理

JWT( JSON WEB TOKEN)原理理解析

一個 JWT token 是一個字符串，它由三部分組成，令牌頭、載荷（payload）與簽名（Signature）
複製代碼

那麼他長生麼樣呢？

如上圖所示，就長這個樣子，三個部分直接用.分隔，接下來咱們一個個解析

令牌頭（header）

header典型的由兩部分組成：token的類型（「JWT」）和算法名稱（好比：HMAC SHA256或者RSA等等）。

{
  "alg": "HS256",
  "typ": "JWT"
}
複製代碼

而後用 Base64Url 編碼獲得頭部，即 ewogICJhbGciOiAiSFMyNTYiLAogICJ0eXAiOiAiSldUIgp9。

JWT簽名算法中，通常有兩個選擇，一個採用HS256,另一個就是採用RS256。 簽名其實是一個加密的過程，生成一段標識（也是JWT的一部分）做爲接收方驗證信息是否被篡改的依據。

RS256 (採用SHA-256 的 RSA 簽名) 是一種非對稱算法, 它使用公共/私鑰對: 標識提供方採用私鑰生成簽名, JWT 的使用方獲取公鑰以驗證簽名。因爲公鑰 (與私鑰相比) 不須要保護, 所以大多數標識提供方使其易於使用方獲取和使用 (一般經過一個元數據URL)。 另外一方面, HS256 (帶有 SHA-256 的 HMAC 是一種對稱算法, 雙方之間僅共享一個 密鑰。因爲使用相同的密鑰生成簽名和驗證簽名, 所以必須注意確保密鑰不被泄密。

在開發應用的時候啓用JWT，使用RS256更加安全，你能夠控制誰能使用什麼類型的密鑰。另外，若是你沒法控制客戶端，沒法作到密鑰的徹底保密，RS256會是個更佳的選擇，JWT的使用方只須要知道公鑰。

因爲公鑰一般能夠從元數據URL節點得到，所以能夠對客戶端進行進行編程以自動檢索公鑰。若是採用這種方式，從服務器上直接下載公鑰信息，能夠有效的減小配置信息。

載荷（Payload）

載荷中放置了 token 的一些基本信息，以幫助接受它的服務器來理解這個 token。同時還能夠包含一些自定義的信息，用戶信息交換。

載荷的屬性也分三類：

• 預約義（Registered）
• 公有（public）
• 私有（private）

咱們先來看預約義,這裏面的前 7 個字段都是由官方所定義的，也就是預約義（Registered claims）的，並不都是必需的。

{
  "sub": "1", //主題
  "iss": "http://localhost:8000/auth/login",//該JWT的簽發者
  "iat": 1451888119,//在何時簽發的
  "exp": 1454516119,// 何時過時，這裏是一個Unix時間戳
  "nbf": 1451888119,//生效時間，在此以前是無效的
  "jti": "37c107e4609ddbcc9c096ea5ee76c667",//編號
  "aud": "dev"//受衆

複製代碼

公有的聲明

公共的聲明能夠添加任何的信息，通常添加用戶的相關信息或其餘業務須要的必要信息.但不建議添加敏感信息，由於該部分在客戶端可解密.

私有聲明

{
"sub":"1234567890",// 預約義
"name":"hore_brother",
"admin":true
}
複製代碼

私有聲明是提供者和消費者所共同定義的聲明，通常不建議存放敏感信息，由於base64是對稱解密的，意味着該部分信息能夠歸類爲明文信息。

這個指的就是自定義的聲明。好比前面那個結構舉例中的admin和name都屬於自定的私有聲明。這些聲明跟JWT標準規定的聲明區別在於：JWT規定的聲明，JWT的接收方在拿到JWT以後，都知道怎麼對這些標準的聲明進行驗證(還不知道是否可以驗證)；而私有聲明不會驗證，除非明確告訴接收方要對這些聲明進行驗證以及規則才行。

將上面的 json 進行 Base64Url 編碼獲得載荷，，即 CnsKICAic3ViIjogIjEiLAogICJpc3MiOiAiaHR0cDovL2xvY2FsaG9zdDo4MDAwL2F1dGgvbG9naW4iLAogICJpYXQiOiAxNDUxODg4MTE5LAogICJleHAiOiAxNDU0NTE2MTE5LAogICJuYmYiOiAxNDUxODg4MTE5LAogICJqdGkiOiAiMzdjMTA3ZTQ2MDlkZGJjYzljMDk2ZWE1ZWU3NmM2NjciLAogICJhdWQiOiAiZGV2Igp9。

注意：base64是一種編碼，它是能夠被翻譯回原來的樣子來的。它並非一種加密過程。

簽名（Signature）

jwt的簽名信息由三部分組成：header (base64後的)，payload (base64後的)，secret(祕鑰)
複製代碼

拿到這三部分以後，使用加密算法加密以後編碼生成最後的簽名部分。若是以 HMACSHA256 加密，

HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret
)
複製代碼

你是否是以爲很麻煩，其實社區已經有封裝的庫了。

// jsonwebtoken.js
const jsonwebtoken = require('jsonwebtoken')
const secret = '12345678'
const opt = {
  secret: 'jwt_secret',
key: 'user' }
const user = {
  username: 'abc',
  password: '111111'
}
const token = jsonwebtoken.sign({
data: user,
// 設置 token 過時時間
exp: Math.floor(Date.now() / 1000) + (60 * 60),
}, secret)
console.log('⽣生成token:' + token)
// ⽣生成 token:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjp7InVzZXJuYW1lIjoiYWJjIiw icGFzc3dvcmQiOiIxMTExMTEifSwiZXhwIjoxNTQ2OTQyMzk1LCJpYXQiOjE1NDY5Mzg3OTV9.VPBC QgLB7XPBq3RdHK9WQMkPp3dw65JzEKm_LZZjP9Y
複製代碼

使用上述庫就能經過簡單的api實現token的生成 而且因爲簽名部分的加密祕鑰在服務端，即實現了在客戶端攜帶信息，而且防止篡改。有的人又會問了，他爲啥能防篡改呢？

HMAC 算法是不可逆算法，相似 MD5 和 hash ，但多一個密鑰，密鑰（即上面的 secret）由服務端持有，客戶端把 token 發給服務端後，服務端能夠把其中的頭部和載荷再加上事先共享的 secret 再進行一次 HMAC 加密，獲得的結果和 token 的第三段進行對比，若是同樣則代表數據沒有被篡改。
複製代碼

OAuth(開放受權)

OAuth是在如今的互聯網中的使用很是多，舉個例子，咱們登錄一個網站，你會發現網站上有qq登錄，微信登陸，github 登陸，谷歌登陸等，其實就是OAuth開放受權。

三⽅登⼊主要基於OAuth 2.0。OAuth協議爲⽤用戶資源的受權提供了⼀個安全的、開放⽽⼜ 簡易的標準。與以往的受權⽅式不一樣之處是OAuth的受權不會使第三方觸及到⽤戶的賬號信息 (如⽤用戶名與密碼)，即第三⽅方⽆無需使⽤戶的⽤戶名與密碼就能夠申請得到該⽤戶資源的受權， 所以OAuth是安全的。
複製代碼

瞭解以後，咱們就來簡述一下他的原理。因爲在咱們平常開發中，每一個平臺的對接方式都不同，咱們就以github爲例。大體去還原一下想要實現OAuth受權登陸，須要的操做流程，在這裏只是簡述，如想深刻了解，請去github開發者中心。

假設我有一個網站，而且有用戶體系，每一個用戶須要有一個帳號，此時，有個新來的用戶，想要在當前的帖子上留言，可是他有不想註冊帳號而且還想留言 此時怎麼辦呢？ 這是你會發現，不少大型的網站，他已經註冊了。好比github，而且github提供了一套鑑權機制讓你能這個當前網站能訪問到github的用戶信息，如此一來，你就能訪問就能達到共贏局面，用戶既省去了註冊的繁瑣步驟，你又留住了一個用戶，在互聯網慢慢的發展中這套鑑權機制就叫作OAuth

接下來咱們來開始一步步揭露他的原理步驟，其實，所謂的OAuth鑑權他的本質就是兩個協商的過程，從而肯定網站以及用戶的一一對應關係，而且獲取用戶的意向（贊成仍是不一樣意）

• 網站和 Github 之間的協商
• 用戶和 Github 之間的協商

再根據協商結果去作進一步操做，從而肯定訪問權限。

咱們首先須要知道的是。即便用戶剛登陸過 github，個人網站也不能隨便拿到用戶消息，這顯然是侵犯用戶隱私的，是不安全。因此，咱們必須去進行第一步的協商

網站和 Github 之間的協商

像github這種世界級別的網站，他對受權有着嚴格的權限分類，好比讀取倉庫信息的權限、寫入倉庫的權限、讀取用戶信息的權限、修改用戶信息的權限等等。若是我想獲取用戶的信息，Github 會要求我，先在它的平臺上註冊一個應用，在申請的時候標明須要獲取用戶信息的哪些權限，用多少就申請多少，而且在申請的時候填寫你的網站域名，Github 只容許在這個域名中獲取用戶信息。

此時，若是我若是填了申請，而且審批經過，那麼我算是入了github的白名單了，github會給我發兩個門票，一張門票叫作 Client Id，另外一張門票叫作 Client Secret。

到這裏，第一步就算踏出去了

用戶和 Github 之間的協商

用戶進入個人網站，點擊 github 登陸按鈕的時候，個人網站會把上面拿到的 Client Id 交給用戶，讓他進入到 Github 的受權頁面，Github 看到了用戶手中的門票，就知道這是個人網站讓他過來的，由於一個網站對應一個Client Id，因而它就把個人網站想要獲取的權限擺出來，並詢問用戶是否容許我獲取這些權限。此時，就是最關鍵的一步，獲取用戶受權，防止侵犯隱私。

在代碼上表示其實就是，我去請求一個登陸地址，而後帶上一個令牌和成功以後的回調地址

// 用戶登陸 github，協商
GET https://github.com/login/oauth/authorize

// 協商憑證
params = {
  client_id: "xxxx",
  redirect_uri: "http://my-website.com"
}
複製代碼

若是用戶以爲個人網站要的權限太多，或者壓根就不想我知道他這些信息，選擇了拒絕的話，整個 OAuth 2.0 的認證就結束了，認證也以失敗了結。若是用戶以爲 OK，在受權頁面點擊了確認受權後，頁面會跳轉到我預先設定的 redirect_uri 並附帶一個蓋了章的門票 code。

// 協商成功後帶着蓋了章的 code
Location: http://my-website.com?code=xxx
複製代碼

這個時候，用戶和 Github 之間的協商就已經完成，Github 也會在本身的系統中記錄此次協商，表示該用戶已經容許在個人網站訪問上直接操做和使用他的部分資源。

執行上面兩步以後，鑑權的主體已經完成，剩下的咱們只須要拿着code碼去獲取github

去github驗證拿到最終統統行證

第二步中，咱們已經拿到了蓋過章的門票 code，但這個 code 只能代表，用戶容許個人網站從 github 上獲取該用戶的數據，若是我直接拿這個 code 去 github 訪問數據必定會被拒絕，由於任何人均可以持有 code，github 並不知道 code 持有方就是我本人。

還記得以前申請應用的時候 github 給個人兩張門票麼，Client Id 在上一步中已經用過了，接下來輪到另外一張門票 Client Secret。

如此一來，雙證齊全，就能知道當前的這個受權用戶是從我這個網站出來的。因而，就會給你發一個最終通行證，也就是access_token，模擬代碼以下

// 網站和 github 之間的協商
POST https://github.com/login/oauth/access_token

// 協商憑證包括 github 給用戶蓋的章和 github 發給個人門票
params = {
  code: "xxx",
  client_id: "xxx",
  client_secret: "xxx",
  redirect_uri: "http://my-website.com"
}
複製代碼

// 拿到最後的通行證
response = {
  access_token: "e72e16c7e42f292c6912e7710c838347ae178b4a"
  scope: "user,gist"
  token_type: "bearer",
  refresh_token: "xxxx"
}
複製代碼

從github獲取用戶信息在個人網站使用

上一步 github 已經把最後的通行證 access_token 給我了，經過 github 提供的 API 加通行證就可以訪問用戶的信息了，能獲取用戶的哪些權限在 response 中也給了明確的說明，scope 爲 user 和 gist，也就是隻能獲取 user 組和 gist 組兩個小組的權限，user 組中就包含了用戶的名字和郵箱等信息了。

// 訪問用戶數據
GET //api.github.com/user?access_token=e72e16c7e42f292c6912e7710c838347ae178b4a
複製代碼

// 告訴我用戶的名字和郵箱
response = {
  username: "好學習吧",
  email: "8888888.abcd@gmail.com"
}
複製代碼

到此爲止簡單的 OAuth登陸認證就到此結束

單點登陸

所謂單點登陸全稱叫作：Single Sign On（簡稱SSO），那究竟什麼是單點登陸呢？

在最初的互聯網系咱們就是單系統，全部的功能都在同一個系統上。

後來，咱們爲了合理利用資源和下降耦合性，因而把單系統拆分紅多個子系統，

而此時，問題來了，我多個系統之間是不通訊的，那麼如何去獲取用戶的登陸狀態呢？好比：淘寶和天貓是兩個獨立的系統，咱們想要保證兩個系統的登陸狀態一致，用戶信息同步。就會用到單點登陸。

單點登陸簡單的說就是在多個系統中，用戶只需一次登陸，各個系統便可感知該用戶已經登陸。

知道了什麼是單點登陸之後，他的原理其實很簡單，而咱們的實現方式其實看起來也很簡單，就是不管使用什麼鑑權模式，只須要讓多個系統之間的認證信息互通便可。可是咱們卻須要解決如下問題。

• Session不共享問題
• Cookie跨域的問題
• 須要單獨開一個認證服務器（csa）

接下來我麼一個個解決

Session不共享問題

因爲多系統之間Session不共享，那麼此時就必須有一個公共的地方去存儲當前的這個session，如此一來，答案就能夠呼之欲出了好比，開一個公共的Redis,或者登陸功能單獨抽取出來，作成一個子系統等

Cookie跨域的問題

上面咱們解決了Session不能共享的問題，但其實還有另外一個問題。Cookie是不能跨域的，其實也就是瀏覽器同源策略的限制。那麼解決方案，其實也相對清晰。好比：繞開同源策略。兩個網站使用同一個一級域名、或者強制推送cookie 將Token保存在SessionStroage中 在請求的時候攜帶上等

須要單獨開一個認證服務器

第三個問題，實際上是當前的的一個最佳實踐，有着一個成熟的解決方案，叫作CAS （Central Authentication Service）

以下圖就是他的整體原理圖

接下來我麼 來一步步解析

首先模擬了三個服務，分別是CAS、系統A、系統B，它們分別部署在cas.com，systemA.com和systemB.com；CAS這個服務用來管理SSO的會話；系統A和系統B表明着實際的業務系統。我從五個場景分別來講明這個SSO方案的實現細節。下面先來看第一個。

場景一：用戶發起對業務系統的第一次訪問，假設他第一次訪問的是系統A的some/page這個頁面，它最終成功訪問到這個頁面的過程是：

在當前第一個場景中，他的第一個場景在於

• 它用到了兩個cookie(jwt和sid)和三次重定向來完成會話的建立和會話的傳遞；

• jwt的cookie是寫在systemA.com這個域下的，因此每次重定向到systemA.com的時候，jwt這個cookie只要有就會帶過去；

• sid的cookie是寫在cas.com這個域下的，因此每次重定向到cas.com的時候，sid這個cookie只要有就會帶過去；

• 在驗證jwt的時候，如何知道當前用戶已經建立了sso的會話？由於jwt的payload裏面存儲了以前建立的sso 會話的session id，因此當cas拿到jwt，就至關於拿到了session id，而後用這個session id去判斷有沒有的對應的session對象便可。

• CAS服務裏面的session屬於服務端建立的對象，因此要考慮session id惟一性以及session共享（假如CAS採用集羣部署的話）的問題。session id的惟一性能夠經過用戶名密碼加隨機數而後用hash算法如md5簡單處理；session共享，能夠用memcached或者redis這種專門的支持集羣部署的緩存服務器管理session來處理。

• 因爲服務端session具備生命週期的特色，到期需自動銷燬，因此不要本身去寫session的管理，省得引起其它問題，到github裏找開源的緩存管理中間件來處理便可。存儲session對象的時候，只要用session id做爲key，session對象自己做爲value，存入緩存便可。session對象裏面除了session id，還能夠存放登陸以後獲取的用戶信息等業務數據，方便業務系統調用的時候，從session裏面返回會話數據。

場景二：用戶登陸以後，繼續訪問系統A的其它頁面，如some/page2，它的處理過程是：

從這一步能夠看出，即便登陸以後，也要每次跟CAS校驗jwt的有效性以及會話的有效性，其實jwt的有效性也能夠放在業務系統裏面處理的，可是會話的有效性就必須到CAS那邊才能完成了。當CAS拿到jwt裏面的session id以後，就能到session 緩存服務器裏面去驗證該session id對應的session對象是否存在，不存在，就說明會話已經銷燬了（退出）。

場景三：用戶登陸了系統A以後，再去訪問其餘系統如系統B的資源，好比系統B的some/page，它最終能訪問到系統B的some/page的流程是：

這個過程的關鍵在於第一次重定向的時候，它會把sid這個cookie帶回給CAS服務器，因此CAS服務器可以判斷出會話是否已經創建，若是已經創建就跳過登陸頁的邏輯。

場景四：用戶繼續訪問系統B的其它資源，如系統B的some/page2：

場景五：退出登陸，假如它從系統B發起退出，最終的流程是：

最重要的是要清除sid的cookie，jwt的cookie可能業務系統都有建立，因此不可能在退出的時候還挨個去清除那些系統的cookie，只要sid一清除，那麼即便那些jwt的cookie在下次訪問的時候還會被傳遞到業務系統的服務端，因爲jwt裏面的sid已經無效，因此最後仍是會被重定向到CAS登陸頁進行處理。

到此爲止，sso 單點登陸基本結束了，咱們只作瞭解便可，由於大部分業務中基本用不上，咱們到目前爲止作的單點登陸就是攜帶token跳轉，雖然不安全，可是能快速應用。在面對快速業務開發的咱們。是個最優選擇

最後

首先感謝巨人

OAuth 受權的工做原理是怎樣的？足夠安全嗎？ 看圖理解JWT如何用於單點登陸

斷斷續續數日，終於將基本的用戶鑑權機制的原理整理完成，在我整理完而且本身造成本身的知識體系以後分享出來，但願對你們有幫助！