登錄工程：現代Web應用的典型身份驗證需求
朋友就職于某大型互聯網公司。前不久，在閑聊間我問他日常工作的內容，他說他所在部門只負責一件事，即用戶與登錄。
而他的具體工作則是為各個業務子網站提供友好的登錄部件(Widget)，從而統一整個網站群的登錄體驗，同時也能令業務開發者不用花費額外的精力去關注用戶鑒權。這很有趣。
可以看出，在一個現代Web應用中，圍繞“登錄”這一需求，儼然已經衍生出了一個新的工程。不管是我們面臨的需求，還是解決這些需求所運用的方法與工具，都已經超出了傳統Web應用身份驗證技術的范疇。
在之前一篇文章中，我聊到傳統Web應用中的身份驗證技術，文章中列出的一些方法在之前很長一段時間內，為滿足大量的Web應用中身份驗證的需求提供了思路。在這篇文章里，我將簡要介紹現代Web應用中幾種典型的身份驗證需求。
形式多樣的鑒權
考慮這樣一個場景：我們在電腦上登錄了微軟賬號，電腦里的“郵件”應用能夠自動同步郵件了;我們登錄Web版本的Outlook郵件服務，如果在郵件里發現了重要的工作安排，將其添加到日歷中，很快電腦里的“日歷”應用便能夠將這些日程顯示到Windows桌面上。
這個場景包含了多個鑒權過程。至少涉及了對Web版本Outlook服務的鑒權，也涉及了對離線版本的郵件應用的鑒權。要能夠支持同一批用戶既能夠在瀏覽器中登錄，又能夠在移動端或本地應用登錄(例如 Windows UWP 應用程序)，就需要開發出能夠為兩種應用程序服務的鑒權體系。
在瀏覽器里，我們通常假設用戶不信任瀏覽器，用戶通過與服務器建立的臨時瀏覽器會話完成操作。會話開始時，用戶被重定向到特定頁面進行登錄。登錄完成后，用戶通過持續與服務器交互來延續臨時會話的時長;一旦用戶一段時間不與服務器交互，則他的會話很快就會過期(被服務器強制登出)。
在移動應用中，情況有所不同。相對來說，安裝在移動設備中的應用程序更受用戶信任，移動設備本身的安全性也比瀏覽器更好。另一方面，將用戶重定向到一個網頁去登錄的做法，并不能提供很好的用戶體驗——更重要的是，用戶在使用移動設備時，時間是碎片化的。我們無法要求用戶必須在特定時間內完成操作，也就基本沒有會話的概念：我們需要找到一種能夠安全地在設備中相對持久地存儲用戶憑據的方法，并且Web應用服務器可能需要配合這種方式來完成鑒權。此外，移動設備也不是絕對安全的，一旦設備丟失，將給用戶帶來安全風險。所以需要在服務器端提供一種機制來取消已登錄設備的訪問權限。
(圖片來自：http://docs.identityserver.io/en/release/intro/big_picture.html)
方便用戶的多種登錄方式
“輸入用戶名和密碼”作為標準的登錄憑據被廣泛用于各種登錄場景。不過，在Web應用、尤其是互聯網應用中，網站運營方越來越發現使用用戶名作為用戶標識確實給網站提供了便利，但對用戶來說卻并不是那么有幫助：用戶很可能會忘記自己的用戶名。
用戶在使用不同網站的過程中，為了不忘記用戶名，只好使用相同的用戶名。如果恰好在某個網站遇到了該用戶名被占用的情況，他就不得不臨時為這個網站擬一個新的用戶名，于是這個新用戶名很快就被忘記了。
在注冊時，越來越多的網站要求用戶提供電子郵箱地址或者手機號碼，有的網站還支持讓用戶以多種方式登錄。比如，提供一種讓用戶在使用了一種方式注冊之后，還能綁定其他登錄方式的功能。綁定完成之后，用戶可以選用他喜歡的登錄方式。它隱含了一個網站與用戶共同的認知：聯系方式的擁有者即為用戶本人，這種“從屬”關系能夠用于證實用戶的身份。當用戶下次在注冊新網站時遇到“郵件地址已被注冊”，或者“手機號已被注冊”的時候，基本可以確定自己曾經注冊過這個網站了。
(圖片來自：http://cargocollective.com/)
另外，登錄過程中所支持的聯系方式也呈現出多樣性。電子郵件服務在很多場景中逐漸被形式多樣的其他聯系方式(比如手機、微信等)所取代，不少人根本沒有使用郵件的習慣，如果網站只提供郵箱注冊的途徑，有時候還會遭到那些不經常使用電子郵箱的用戶的反感。所以支持多種登錄方式成為了很多網站的迫切需求。
雙因子鑒權：增強型登錄過程
上一節中提到的“從屬”關系不光可以幫助用戶判斷自己是否注冊過一個網站，也可以幫助網站在忘記密碼時進行臨時認證，從而幫助用戶完成新密碼的設置。如果將這種從屬關系用于正常登錄過程中的進一步驗證，就構成了雙因子鑒權。
雙因子鑒權要求用戶在登錄過程中提供兩種形式不同的憑據，只有兩種驗證都成功才能繼續操作。現代化Web應用正在越來越多地使用這種增強型驗證方式來保護關鍵操作的安全性。例如，查看和修改個人信息，以及修改登錄密碼等。
相信不少人還記得QQ密碼保護問題的機制，它使得盜號者即使盜取了QQ密碼，在不知道密碼保護問題的情況下，也無法修改現有密碼，讓賬號擁有者得以及時挽回損失。
雙因子的原理在于：兩種驗證因子性質不一致，冒用身份者同時獲得用戶這兩種信息的機率十分低，從而能有效地保護賬號的安全。在QQ密碼保護的例子里，密碼是一種每次登錄時都會使用的固定文本、相對容易被盜;而密碼保護問題卻是不怎么頻繁設置和更改的、隱秘的、個人關聯性極強的，不容易被盜。
(圖片來自：http://bit.ly/2kFc492)
現代化Web應用形式多樣，設備種類繁多，場景復雜多變，而為了更好地保護用戶賬號的安全，很多應用開始將雙因子驗證作為登錄過程中的鑒權步驟。而為了兼具安全和便利的特點，一些應用還要求運用一些優化策略以提高用戶體驗。比如，僅在用戶在新的設備上登錄、一段時間未登錄之后的再次登錄、在不常用的地點登錄、修改聯系信息和密碼、轉移賬戶資產等關鍵操作時要求雙因子鑒權。
單點登錄：還是需要精心設計
以前，一般只有大型網站、向用戶提供多種服務的時候(比如，網易公司運營網易門戶和網易郵箱等多種服務)，才會有單點登錄的迫切需求。但在現代化Web系統中，無論是從業務的多元化還是從架構的服務化來考慮，對服務的劃分都更細致了。
從整個企業的業務模式(例如網易門戶和網易郵箱)，到某項業務的具體流程(例如京東訂單和京東支付)，再到某個流程中的具體步驟(例如短信驗證與支付扣款)，“服務”這一概念越來越輕量級，于是人們不得不創造了“微服務”這個新的品類詞匯來拓展認知空間。
(圖片來自：http://cargocollective.com/)
在這整個的演變過程中，出于安全的需要，身份驗證的需求都是一直存在的，而且粒度越來越細。以前我們更關注用戶在多個子站點的統一登錄體驗，現在我們還需要關注用戶在多個子流程中的統一登錄體驗，以及在多個步驟中的統一登錄體驗。而這些流程和步驟，很可能是獨立的Web系統(微服務)，也有可能是一個用戶界面(獨立應用)，還有可能是一個第三方系統(接口集成)。
可以說，單點登錄的需求有增無減，只不過當開發者對這種模式已經習以為常，不再意識到這也是一個能夠專門討論的話題。
考慮與用戶系統集成，與業務系統分離
在討論安全時，分不開的兩個部分就是鑒權與授權。
鑒權的過程是向用戶發起質詢(Challenge)，完成身份驗證工作。這正是登錄所解決的問題。通常在登錄系統成功識別用戶之后，就會將接下來的工作直接交給業務系統來完成。由于各個系統中的授權模型可能與業務形態有關系，因此登錄與業務系統分離是很自然的設計。
在對安全要求更嚴格的企業或企業應用中，可能需要專門的訪問管理機制，不過，這樣的做法在互聯網應用中很少見。但在互聯網Web應用中，授權的范疇也包含一個很小的公有部分，是各個業務系統所共有的：即用戶狀態。我們希望在各業務子系統之間共享用戶狀態：用戶被鎖定之后，他在所有業務系統都被鎖定;用戶被注銷之后，所有業務系統中有關他的數據都被封存。
另外在多個業務系統中，還可能會共用用戶的基本資料和偏好設置等數據。比如，類似于郵件地址這樣的資料，它可以作為登錄憑據，也可以作為一個基本的聯系方式。如果用戶在一個子系統設置了偏好語言，其他子系統則直接使用該設置即可。這樣，開發一個“用戶”系統的想法也就應運而生了。由于與用戶的狀態等基礎信息的關系很緊密，登錄與用戶系統之間的集成是很自然的，將登錄子系統直接作為這個用戶系統的一部分也不失為一種不錯的實踐。
與第三方集成：迎接更多用戶
“即得”是一個開放式文檔共享應用，特點是“無需登錄，即傳即得”，它利用長時間有效的Cookie來標識用戶，從而免除了人們使用應用之前必須注冊登錄的繁瑣步驟。
這種做法的風險是，如果用戶有及時清理瀏覽器Cookie的習慣，那很可能導致用戶再一次登錄時不再被識別。不過從這樣一個小例子中，卻容易看出登錄的真正作用，就是Web應用識別用戶的過程，當下次同一個用戶再次使用時，Web應用就能夠知道“這就是上次來過的那個用戶”。
如果識別用戶這一需求能夠在不需要用戶注冊的前提下搞定，豈不兩全齊美?基于第三方身份提供方的接口來識別已經在其他平臺注冊的用戶，并將其轉化為自己應用中的用戶，這種方式完全可行，并且大量的開發人員已經有了豐富的實踐。
從 2010 年開始就有不少的大型互聯網公司開始推出開放平臺服務，讓第三方應用通過Web接口與這些互聯網服務交互，從而為他們提供更豐富多彩的功能。在這個過程中，一些應用不為這些平臺提供擴展，卻巧辟蹊徑地利用了這些開放平臺的身份識別接口來免除新用戶注冊的過程，從而為自己的產品快速導入用戶。不少網站都提供“使用微博賬號登錄”功能，相信讀者一定體驗過。
(圖片來自：http://bit.ly/2kFi3e8)
如果你的應用需要向第三方提供用戶，那么我們的角色就由“從上下文中讀取用戶身份”變成了“向上下文中寫入用戶身份”了。如果你正好有過與各互聯網公司開放平臺的接口打交道的經歷，這時候，你就可以體驗一把提供開放、安全上下文的挑戰了。如果……你的平臺既希望讓其他平臺的用戶能夠平滑接入，又希望向其他平臺公開自己的用戶，那可能是另一番更有趣的挑戰。這個過程，也可以作為生物驗證之外的另一種間接消除密碼的實踐方式吧。
登錄，現在實實在在地成為了一個獨立的工程。尤其在形態多樣的基于Web的應用，以及這些Web應用本身所依賴的各色后端服務快速生長的過程中，各種鑒權需求隨之而來。如何在保障各個環節中安全的同時，又為用戶提供良好的體驗，成為一個挑戰。
另外，個人信息泄露的事件頻繁被曝光，它們導致的社會問題也開始被更多人關注和重視，作為IT系統支撐者的工程師們有責任了解事關安全的基礎知識，并掌握必要的技能去保護用戶數據和企業利益。
我會在接下來的文章中介紹解決典型登錄需求的具體技術方案，以及相關領域的安全實踐常識。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
