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