04-⾝份認證： 除了賬号密碼 ，我們還能怎麼做⾝份認證？

上⼀講 ，我們詳細講解了密碼學的三種算法：⾼效安全的對稱加密算法 ，解決密鑰分發難題的⾮對稱加密算法 ， 以及提供單向加密的散列算法。

在表達了你對密碼學清晰的理解之後 ，⾯試官開始相信你具備安全⽅⾯的基礎知識了。于是 ，他準備和你探讨⼀ 下安全落地的細節。基于你之前提出的“⻩⾦法則” ，⾯試官問道：“⻩⾦法則的認證(Authentication) 部分不就是賬号密碼嗎？這麼簡單的東西 ，有必要考慮得那麼複雜嗎？”

認證 ，也就是⾝份識别與認證 (通常來說 ，識别和認證是⼀體的 ，因此後⾯我會⽤⾝份認證來指代識别和認證) 。毫⽆疑問 ，對于⼀個安全的應⽤來說 ，⾝份認證是第⼀ 道⻔檻 ，它為後續所有的安全措施提供“⾝ 份”這樣 一個關鍵信息。聽完你的簡單叙述後 ，⾯試官直接問道：“現在我們公司有好⼏個應⽤ ，每⼀個應⽤都有獨⽴的賬号體系，管理起來⼗分複雜。⽽且 ， 内部員⼯的賬号體系也沒有建設起來。如果是你 ，你會怎麼解決這些問題呢？”

現在你可能很難回答這些問題 ，沒關系 ，帶着這些問題 ，讓我們來學習今天的内容。相信學完之後 ，再有⼈問 ，你都可以對答如流。

⾸先 ，⾝份認證不僅僅是⼀ 個輸⼊賬号密碼的登錄⻚⾯⽽已 ，應⽤的各個部分都需要涉及⾝份認證。在我看來 ，⾝份認證可以分為兩個部分：對外認證和對内認證。

對外認證 ，其實就是應⽤的登錄注冊模塊 ，它⾯向⽤⼾進⾏認證。對外認證的⼊⼝⽐較集中 ，⼀ 個應⽤通常 隻有⼀ 個登錄⼊⼝ 。因此 ，我們可以在登錄這個功能上 ，實現很多種認證的⽅式。這就可以⽤到我們之前提

到的“你知道什麼、你擁有什麼、你是什麼”。

除了應⽤本⾝需要有登錄注冊的模塊 ，應⽤的各種内部系統同樣需要涉及登錄認證的功能 ，⽐如：服務器的 登錄、數據庫的登錄、Git的登錄、各種内部管理後台的登錄等等。這也就是我所說的對内認證。

那麼 ，對内認證和對外認證有什麼區别呢？ 我覺得 ， 它們最主要的區别在于認證場景的複雜程度。 從下⾯這張圖中我們可以看出 ，對外認證是單⼀場景下的認證 ，對内認證是多場景下的認證。⽬前還⽆法做到統⼀ 。因此 ，對内認證是⼀ 個⻓期治理的過程 ，需要我們投⼊較⼤的精力。

在了解了對内、對外認證的特點之後 ，我們再來聊⼀ 聊它們的應⽤ 。我了解到的⽬前⾏業的現狀是 ，各個公

司的對内認證都⽐較薄弱。其主要原因在于 ， 内部的認證場景過于分散 ，很難進⾏統⼀ 管理。尤其是服務精⼒。

正如我在第⼀節課中提到的 ，“⾯對一個問題時 ，我們總是很容易發現表⾯的影響 ，⽽忽視其産⽣的根本原因” ， 在⾝份認證這個問題上同樣如此。 表⾯上 ， 我們要做好對外認證 ， 防⽌用戶的賬号被盜。 根本上或者說更普遍的問題是 ，我們要如何做好對内認證。 因此 ， 當你在考慮⾝份認證的安全問題時 ，⼀ 定要盡可能考慮得更全⾯ 。畢竟 ，對于安全來說 ，有⼀ 個⼩場景沒做到位 ，很多時候 ，就意味着什麼都沒做。

接下來 ，你肯定想問 ，我們該如何做好⾝份認證呢？ 不要着急 ，我們先來看⼀ 下⾝份認證都會⾯臨哪些威脅。 隻要我們針對這些威脅找到對應的解決辦法 ， 就能做好⾝份認證了。 ⾝份認證⾯臨的威脅主要包括⽆認證、弱密碼、 認證信息洩漏。 接下來 ，我們⼀ 個⼀ 個來看。

⾸先 ，沒有認證環節是所有應⽤和公司存在的最普遍的問題。尤其是在對内認證的部分 ，我們經常會看到， 很多公司的數據庫、接⼝ 、管理後台在使⽤的時候 ，并不需要經過認證這個環節。除了沒有認證環節的直接“裸奔” ，弱密碼也是⼀ 個普遍存在的問題。我常常覺得 ，安全最⼤的敵⼈是⼈類的惰性。設計⼀ 個好記的強密碼并不是⼀ 件簡單的事情 ，這也是弱密碼屢禁不⽌的原因。說完了⽆認證和弱密碼 ，接下來我們來聊⼀ 聊認證信息洩漏。 所謂認證信息洩露 ，就是指⿊客通過各種⼿段 ，拿到了⽤⼾的密碼信息和⾝份憑證這樣的認證信息。 常⻅的⼿段包括釣⻥ 、拖庫等等。 更可怕的是 ，很 多攻擊對于用戶來說都是⽆感知的。

那麼 ，⽆感知體現在哪⾥呢？你都不知道你的密碼已經被洩露了。

除了密碼的直接洩漏以外 ，⼤部分的登錄系統都⽆法應對重放攻擊。重放攻擊簡單來說就是 ，⿊客在竊取到 ⾝份憑證 (如Cookie、Session ID) 之後 ，就可以在⽆密碼的情況下完成認證了。

總結來說 ，⾝份認證⾯臨的威脅其實都是認證信息的洩漏。 這其中 ， 既可能是應⽤本⾝就沒有認證信息或者認證信息強度⽐較弱 ，使得⿊客可以通過猜測的⽅式快速獲取認證信息； 也有可能是⿊客通過⼀ 些攻擊⼿段(如竊聽等) ， 從用戶那獲取了認證信息 ， 從⽽冒充用戶進⾏登錄。⽽⾝份認證被破解的後果 ，相信你也知道⼀ 些： ⼀ 旦⿊客仿冒了正常用戶進⾏認證 ，那麼就相當于獲得了這個用戶的所有權限。 更嚴重的是 ，所有的後續操作 ，都會記錄到這個正常⽤⼾的名下 ，使得後續應⽤進⾏授 權和審計的時候 ，都很難發現⿊客本⾝的存在。

在了解了⾝份認證環節會⾯臨的各種威脅 ， 以及這些威脅可能産⽣的影響之後 ，你可能要問了 ，我們應該怎麼解除這些威脅呢？ 我覺得 ，很多時候 ， 我們解決安全問題 ，不隻是在解決⼀個技術問題 ，還要培養外部⽤⼾和内部員⼯的安全意識。 也就是說 ， 認證安全并沒有什麼完善的技術解決⽅案 ， 更多的是通過⼀ 些規章制度去強化我們的安全意識。

盡管如此 ，我這⾥也會去講⼀ 些技術⽅案 ，讓你知道⼀ 些基本的解決⽅案。

⽐如 ，對密碼的強度進⾏限制 (如強制使⽤字⺟ 、數字、 特殊字符的組合密碼 ，并達到⼀ 定⻓度) ，強制⽤⼾定期修改密碼 ， 對關鍵操作設置第⼆密碼 (如微信、 ⽀付寶的⽀付密碼) 等等。

當然 ，随着互聯⽹的發展 ，我們也會不斷地利⽤新技術去升級驗證⼿段 ，幫助⽤⼾降低被“攻擊”的⻛險。 ⽐如 ，通過⼿機驗證替代密碼驗證 (因為丢失⼿機的⼏率⽐丢失密碼的⼏率低) ；通過⼈臉、指紋等⽣物特 征替代密碼。除此之外 ，我們還可以通過加密信道 (如HTTPS) 來防⽌竊聽； 也可以通過給下發的憑證設置⼀ 個有效期 ， 來限制憑證在外暴露的時間 ， 以此來減少重放攻擊帶來的影響。

這⾥⾯有⼀ 點你要注意 ，⾝份認證的最⼤的問題還是在于⾝份管理。 随着公司業務的不斷擴張 ， 當賬号體系變得越來越複雜時 ，如何對這些賬号進⾏統⼀ 的管理 ，是解決⾝份認證問題的關鍵。⽽ 單點登錄就是⼀ 個⾮常有效的解決⽅案。

那麼單點登錄 (Single Sign On ，SSO) 到底是什麼呢？ 單點登錄的概念很簡單： ⽤⼾隻需要進⾏⼀ 次認證 ，就可以訪問所有的⽹⻚ 、應⽤和其他産品了。 随着互聯⽹産品形式的不斷發展 ，單點登錄的實現⽅式也 經曆了多次的升級⾰新。 下⾯我為你介紹⼏種典型的單點登錄⽅式 ， 它們分别是： CAS流程、JWT、 OAuth和OpenID。

第⼀ 個要講的是CAS (Central Authentication Service ，集中式認證服務) 流程。

CAS是⼀ 個開源的單點登錄框架 ， 它不屬于某⼀種單點登錄的實現⽅式 ，⽽是提供了⼀ 整套完整的落地⽅

案。 整體的流程如下圖所⽰ ， 具體步驟我會通過訪問極客時間App的例⼦來為你詳細講解。

1. 假如⽤⼾現在要訪問某個應⽤ ，⽐如極客時間App。

2. 應⽤需要進⾏認證 ，但應⽤本⾝不具備認證功能。 因此 ， 應⽤将⽤⼾重定向⾄認證中⼼的⻚⾯ 。 ⽐如，你在登錄⼀ 個應⽤的時候 ， 它顯⽰你可以選擇微信、 QQ、 微博賬号進⾏登錄 ，你點擊微信登錄 ， 就跳轉⾄微信的登錄⻚⾯了。

3. ⽤⼾在認證中⼼⻚⾯進⾏認證操作。如果⽤⼾之前已經在其他應⽤進⾏過認證了 ，那麼認證中⼼可以直接識别⽤⼾⾝份 ， 免去⽤⼾再次認證的過程。

4. 認證完成後 ，認證中⼼将認證的憑據 ，有時會加上⽤⼾的⼀ 些信息 ，⼀ 起返回給客⼾端。 也就是你在微 信登錄完成後 ， 回到了極客時間App。

5. 客⼾端将憑據和其他信息發送給應⽤ ，也就是說 ，極客時間App将微信的登錄憑據發送給了極客時間後 端。

6. 應⽤收到憑據後 ，可以通過簽名的⽅式 ，驗證憑據的有效性。或者 ，應⽤也可以直接和認證中⼼通信， 驗證憑據并獲取⽤⼾信息。這也就是為什麼極客時間能夠拿到你的微信頭像了。

7. ⽤⼾完成認證。

CAS的流程⾮常經典 ，你現在應該理解了吧？ 我們後⾯要講的3種單點登錄⽅式 ，都和CAS的流程相似 ， 說它們是CAS的“衍⽣品”也不為過。 所以說 ，你⼀ 定要先掌握了CAS流程 ，然後再來看下⾯這3種。

JWT (JSON Web Token) 是⼀ 種⾮常輕量級的單點登錄流程。 它會在客⼾端保存⼀ 個憑證信息 ，之後在你每⼀ 次登錄的請求中都帶上這個憑證 ，将其作為登錄狀态的依據。JWT的好處在于 ，不需要應⽤服務端去額外維護Cookie或者Session了。但是 ，正是因為它将登錄狀态落到了客⼾端 ，所以我們⽆法進⾏注銷等操作了。

OAuth (Open Authorization) 的主要特點是授權 ，也是我們通常⽤QQ、微信登錄其他應⽤時所采⽤的協議。通過OAuth ，⽤⼾在完成了認證中⼼的登錄之後 ，應⽤隻能夠驗證⽤⼾确實在第三⽅登錄了。但是 ，想要維持應⽤内的登錄狀态 ， 應⽤還是得頒發⾃⼰的登錄憑證。 這也就是為什麼QQ授權後 ， 應⽤還需要綁定你的⼿機号碼。 這也就意味着 ，應⽤是基于QQ的信息創建了⼀ 個⾃⾝的賬号。

OpenID (Open Identity Document) 和OAuth的功能基本⼀ 緻。但是 ，OpenID不提供授權的功能。 最常⻅的 ， 當我們需要在應⽤中使⽤微信⽀付的時候 ，應⽤隻需要收集⽀付相關的信息即可 ，并不需要獲取⽤⼾ 的微信頭像。

在實際情況中 ，基于各種業務需求的考慮 ，很多公司都傾向于⾃⼰去實現⼀ 套SSO的認證體系 ， 它的認證流程如下圖所⽰：

在這個流程中 ，應⽤的服務器直接接收⽤⼾的認證信息 ，并轉發給認證中⼼。對⽤⼾來說 ，這個認證中⼼是 完全透明的。但是 ，這個流程給予了應⽤過多的信任 ，從安全性⽅⾯考量的話 ，是不合理的。在這個過程 中 ，應⽤直接獲取到了⽤⼾的認證信息 ，但應⽤能否保護好這些信息呢？我們并沒有有效的辦法去做确認。

因此 ，我的建議是 ，多花⼀些功夫去接⼊成熟的單點登錄體系 ，⽽不是⾃⼰去實現⼀ 個簡化版的。JWT适⽤範圍⼴ ，在單點登錄的選取上⾯ ，如果想要将⽤⼾信息做統⼀ 管理 ，選擇它最為簡單；如果認證中⼼隻是被⽤來維護賬号密碼 ， 由業務去維護⽤⼾所綁定的其他⼿機等信息 ，那麼 ，采⽤OAuth更合适。

好了 ，今天的内容差不多了 ，下⾯我來帶你總結回顧⼀ 下 ，你要掌握的重點内容。

⾝份認證的主要場景可以分為：對外認證和對内認證。其中 ，對内認證往往會因為管理的疏忽 ，導緻很嚴重的問題。 從威脅上來說 ，⽆認證和弱密碼 ，是最普遍的安全問題。 除此之外 ，各種密碼和認證信息的竊取，也是⿊客常⽤的攻擊⼿段。 對于⾝份認證來說 ，單點登錄是⼀種集⼤成的解決⽅案。 基于CAS流程 ，衍⽣出了很多成熟的單點登錄流程 ，可以供你去使⽤ 。

那麼 ，掌握⾝份認證的⼀ 些技巧 ，對我們有哪些幫助呢？⾸先 ，任何的應⽤都會存在對内和對外的認證 ，因 此 ，這将是你提升應⽤安全⽔平的⼀ 個⾸要任務。其次 ，在複雜的應⽤系統和⽹絡結構中 ，如何管理⾝份認 證 ，既優化⽤⼾體驗 ，⼜保證其安全性 ，對你的設計和管理能⼒都是⼀ 個考驗。做好了⾝份認證 ，不論是在安全上 ，還是在個⼈能⼒上 ，你都能夠得到極⼤的提升。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!