目錄

一、總述
二、環(huán)境配置
[三、業(yè)務(wù)servers管理]
[四、用戶信息同步]
[五、token的攔截、生成、驗證（服務(wù)端）]
[六、概念辨析：session、cookie、token的區(qū)別與token存儲]
[七、token的分享（瀏覽器端）]
[八、安全性措施]
[九、用戶體驗]
[十、性能]

關(guān)于沒有后續(xù)更新的問題

各位，實在抱歉！SSO原本是我的畢業(yè)設(shè)計，但是出于某個原因，我決定留級，畢設(shè)暫時擱淺！這段時間忙著準備面試的事情，系統(tǒng)學習前端中ing! 這是這個系列被擱淺的原因之一！另一個原因在于，我發(fā)現(xiàn)沒有經(jīng)歷過企業(yè)開發(fā)，真的在某些環(huán)節(jié)上很難理解SSO中一些讓我非常困惑的問題！比如，我一直困惑的這個問題，這非常有可能是一個很簡單的問題，但是我往往是被這種問題困惑住。比如，“性能”問題，大四實習年一直沒在IT企業(yè)，討論“性能”心里很虛，我更想接觸一定的開發(fā)之后，心里更加有底的寫下問題的答案。沒出問題的話，這個系列會在6月中旬繼續(xù)更新，希望8月能搞定。

經(jīng)商之道

今天我要講兩個故事，一家高級商場的故事和一家普通商場的故事。

1.高級商場的故事

從前有個老板叫C/S，他開了這樣一家高級商場叫“TCP/IP Server"。專門服務(wù)注冊了VIP的顧客。他們對待注冊了VIP的顧客的服務(wù)非常的高級。怎樣高級？每一位VIP顧客進來購物，就會有一個服務(wù)員全程陪同。這些服務(wù)員提供所有的服務(wù)，非常的有才能。但就是都很沒有記性，永遠都記不住自己是在服務(wù)哪位顧客。這也怪不得服務(wù)員，誰叫每個VIP顧客都長得一模一樣呢？于是老板就讓服務(wù)員全程牽著顧客的手，并且手里拿著一張紙條，紙條上面寫著顧客的姓名、性別、年齡、余額等等信息。這樣他們就能叫出顧客的尊稱，而且因為牽著手，所以不至于跟顧客走丟。真為這一群奇葩著急啊ヽ(￣д￣;)ノ!!!這些服務(wù)員這一群體被學術(shù)家們稱為“progress”，而顧客這一群體被學術(shù)家們稱為“client”

我很好奇高級商場賣的都是些什么東西。從商業(yè)角度來說，全程一對一的服務(wù)成本可真高啊。

2.普通商場的故事

后來，有一個老板叫B/S，他覺得C/S是個傻X，全程一對一的服務(wù)成本高，收益小。于是他開了一家普通的商場叫"HTTP Server"。跟"TCP/IP Server"商場一樣，他的"HTTP Server"也是需要注冊VIP的。但是他的服務(wù)員們并不會全程陪同顧客購物?？偟膩碚f，他們提供兩樣服務(wù)：1.詢問 2.收銀。每個服務(wù)員在處理完某個顧客的詢問服務(wù)或者收銀服務(wù)后，就可以為另一個顧客服務(wù)。"B/S"以為它的商場會比那個沒頭腦的“C/S”的商場收益更好！很顯然嘛，一樣多的服務(wù)員，他的店能服務(wù)更多的顧客。

天真的B/S，可憐的B/S。他差點就破產(chǎn)了～ 還不是那群讓人著急的服務(wù)員！開張第一天，他們就惹來了滿滿的差評。他們總是記不住顧客買了什么東西，根本沒有辦法收銀；而且顧客上前要詢問他們“node.js的產(chǎn)品在哪個貨架？”、“Python有多少種框架產(chǎn)品？”等問題的時候，這群服務(wù)員總是沒有辦法先叫出顧客的名字來給予顧客問候。顧客覺得他們都很沒有禮貌～～～這也怪不得服務(wù)員，健忘是他們的天性，更何況每個顧客的相貌、穿著、聲音又都完全一樣，他們可是要一個人服務(wù)多個顧客的！

B/S決定關(guān)店整改!!!他給每個服務(wù)員配備了一個記錄器。有一個服務(wù)員專門負責把進店的會員信息寫進記錄器，然后把一串唯一的ID寫在一種叫做cookie的紙上，把紙貼在顧客額頭上......沒錯，貼在額頭上。其它服務(wù)員只要往記錄器輸入顧客頭上的ID，就能查詢到顧客的信息，這樣服務(wù)員就不會因為叫不出顧客的名字被說沒禮貌了；并且可以把顧客要買的東西，臨時的記錄在記錄器里面。當然啦，記錄器里的記錄是整個商場共享的。所以，即便顧客A買《黑客與畫家》的時候是服務(wù)員A給記錄的，買《寫給大家看的設(shè)計書》的時候是服務(wù)員B給記錄的，結(jié)算的時候又是服務(wù)員C，他們搞錯了。 B/S非常自豪的把這種記錄器機制叫做session機制，真搞不懂他為什么要這么叫。就這樣，B/S的“HTTP Server”商場以更低的成本獲得了更大的收益～ 他發(fā)跡了。

登錄這件事

登錄就是通過驗證（密碼驗證、指紋驗證、聲音驗證、人面驗證、DNA驗證...），向服務(wù)端表明你是誰？并且讓服務(wù)端記住你是誰。對于C/S的架構(gòu)來說，要記住你是誰太容易了～ 客戶端跟服務(wù)端建立的TCP/IP連接就能很好的表明你誰，一個進程服務(wù)一個客戶端，只要在進程空間里寫個變量就OK了！但是對于B/S架構(gòu)來說，因為是無狀態(tài)的，服務(wù)一結(jié)束就斷開(現(xiàn)在的長連接也還是會斷)，要記住你是誰真心太不容易了～ 所以只能由客戶端來告訴服務(wù)端：“我是誰?！保簿褪墙o客戶端一個ID，然后服務(wù)端有個全局的空間(session)用于記錄ID對于的信息，類似于Map<ID, infomations>。對于每一次的服務(wù)請求，服務(wù)端都要拿著客戶端給的ID，去session查詢這個ID是不是登錄了，如果是則怎樣怎樣，如果不是就叫用戶登錄（假設(shè)每個頁面的訪問都要求用戶登錄）。拿著ID去session查詢ID是不是登錄了這個過程我們把它叫做檢驗，這點先提前說明下，有點重要！登錄成功后，就把這個ID做一個標記，表示登錄。什么樣的標記？你可以在這個ID的session空間里設(shè)置一個變量叫mark用來表示登錄了，但是不會有人這么做的，至少也得設(shè)置個username的變量。不然你怎么知道這個用戶是哪一個用戶呢？有username就可以再去數(shù)據(jù)庫查詢更多的信息，當然也可以把更多的信息寫到session里面，這里不做討論。

什么是單點登錄(Single Sign-On)

很早期的公司，一家公司可能只有一個Server，慢慢的Server開始變多了。每個Server都要進行注冊登錄，退出的時候又要一個個退出。用戶體驗很不好！你可以想象一下，上豆瓣 要登錄豆瓣FM、豆瓣讀書、豆瓣電影、豆瓣日記......真的會讓人崩潰的。我們想要另一種登錄體驗：一家企業(yè)下的服務(wù)只要一次注冊，登錄的時候只要一次登錄，退出的時候只要一次退出。怎么做？

一次注冊。 一次注冊不難，想一下是不是只要Server之間同步用戶信息就行了？可以，但這樣描述不太完整，后續(xù)講用戶注冊的時候詳細說。實際上用戶信息的管理才是SSO真正的難點，只是作為初學者，我們的難點在于實現(xiàn)SSO的技術(shù)！我們先討論實現(xiàn)手段。

一次登錄與一次退出。 回頭看看普通商場的故事，什么東西才是保持登錄狀態(tài)關(guān)鍵的東西？記錄器（session）？那種叫做cookie的紙張？寫在紙張上的ID? 是session里面記錄的信息跟那個ID，cookie只不是記錄ID的工具而已。客戶端持有ID，服務(wù)端持有session，兩者一起用來保持登錄狀態(tài)?？蛻舳诵枰肐D來作為憑證，而服務(wù)端需要用session來驗證ID的有效性（ID可能過期、可能根本就是偽造的找不到對于的信息、ID下對應(yīng)的客戶端還沒有進行登錄驗證等）。但是session這東西一開始是每個server自己獨有的，豆瓣FM有自己的session、豆瓣讀書有自己的session，而記錄ID的cookie又是不能跨域的。所以，我們要實現(xiàn)一次登錄一次退出，只需要想辦法讓各個server的共用一個session的信息，讓客戶端在各個域名下都能持有這個ID就好了。再進一步講，只要各個server拿到同一個ID，都能有辦法檢驗出ID的有效性、并且能得到ID對應(yīng)的用戶信息就行了，也就是能檢驗ID。

單點登錄的實現(xiàn)方法（server端）

以server群如何生成、驗證ID的方式大致分為兩種：

• “共享Cookie”
  這個就是上面提到的共享session的方式，我倒覺得叫“共享session”來得好一點，本質(zhì)上cookie只是存儲session-id的介質(zhì)，session-id也可以放在每一次請求的url里。據(jù)說這種方式不安全，我沒去細究，哪位大神可以推薦下相關(guān)的資料，我后期補上。其實也是，畢竟session這項機制一開始就是一個server一個session的，把session拿出來讓所有server共享確實有點奇怪。

• SSO-Token方式
  因為共享session的方式不安全，所以我們不再以session-id作為身份的標識。我們另外生成一種標識，把它取名SSO-Token(或Ticket)，這種標識是整個server群唯一的，并且所有server群都能驗證這個token，同時能拿到token背后代表的用戶的信息。我們要討論的也是這種方式，一會上具體流程圖。

單點登錄的實現(xiàn)方法（瀏覽器端）

單點登錄還有非常關(guān)鍵的一步，這一步跟server端驗證token的方式無關(guān)，用最早的“共享session”的方式還是現(xiàn)在的“token”方式，身份標識到了瀏覽器端都要面臨這樣的一個問題：用戶登錄成功拿到token(或者是session-id)后怎么讓瀏覽器存儲和分享到其它域名下？同域名很簡單，把token存在cookie里，把cookie的路徑設(shè)置成頂級域名下，這樣所有子域都能讀取cookie中的token。這就是共享cookie的方式（這才叫共享Cookie嘛，上面那個應(yīng)該叫共享session）。比如：谷歌公司，google.com是他的頂級域名，郵箱服務(wù)的mail.google.com和地圖服務(wù)的map.google.com都是它的子域。但是，跨域的時候怎么辦？谷歌公司還有一個域名，youtube.com，提供視頻服務(wù)。如何把身份標識分享給youtube.com這個域？簡單的先提下，后續(xù)會細說。

• 利用帶有src屬性的HTML標簽跨域設(shè)置cookie。例如:

  <iframe width = 0 height=0 src="youtube.com/set_sso_token?ssotoken=iurk2i3f">
  

• url跳轉(zhuǎn)。比如：在google.com登錄后，會跳轉(zhuǎn)到y(tǒng)outube.com下種植cookie，再跳轉(zhuǎn)會google.com。

• Ajax設(shè)置cookie（目前還不了解，據(jù)說京東是這么做的。）

SSO-Token方式的服務(wù)端流程

實際上，基本是用Token代替session的方式，也有非常多種實現(xiàn)方法。圖片是我先去自己實驗時的方案。

SSO-Server負責用戶的登錄（當然也有注冊、修改基本用戶信息、退出功能），它的作用有兩點：

• 驗證用戶。就是驗證賬號密碼。我們略過不關(guān)注

• 生成唯一的token

• 往其它業(yè)務(wù)Server同步token等信息，讓各個業(yè)務(wù)server自己驗證token有效性(如圖)； 或者，提供檢驗token有效性的API接口

我們要實現(xiàn)什么樣的SSO

• token生成與驗證方案：如上圖。

• token在瀏覽器的跨域分享方法，都嘗試一遍。

• 安全性。暫時一律不考慮，我們先關(guān)注實現(xiàn)一個差勁的SSO，再來關(guān)注安全。因為安全是個大話題。太早引入，太拖節(jié)奏

• 實現(xiàn)語言：node.js(express4.x)。其實感覺SSO的實現(xiàn)是語言無關(guān)的，一個node.js實現(xiàn)的登錄server完全可以為一個python實現(xiàn)的業(yè)務(wù)server服務(wù)。server之間的關(guān)系最后都演化成web接口的調(diào)用。