單點登錄系統(tǒng)的類別:
????? 就目前比較流行的應用來看，單點登錄系統(tǒng)主要分為三種類型：一種是基于oauth協(xié)議的網(wǎng)絡令牌(我是這么叫的)，一種是基于Web Service或者簡單Http協(xié)議實現(xiàn)的Passport機制，還有一種是以openid框架形成的通用賬號登錄機制。其中，基于oauth協(xié)議主要應用在網(wǎng)站外部，比較知名的有Google Account、Facebook Connect和新浪微博鏈接等；Passport的應用主要是針對同一網(wǎng)站內(nèi)不同架構不同平臺，知名產(chǎn)品則更是數(shù)不勝數(shù)，例如Google Account賬號基本上可以應用全部Google的網(wǎng)站，而國內(nèi)各大門戶無數(shù)的應用系統(tǒng)也都只需要一個用戶通行證就能暢通無阻；至于OpenID這樣會共享用戶信息的應用，在國外可能會很火，在國內(nèi)這樣一個用戶一寸金的利益集團面前可能會被采納，所以下面的論述也主要針對前面兩種。

單點登錄系統(tǒng)的優(yōu)點:

????? 對于用戶來講，最理想的情況下一個賬號和密碼就可以橫行整個互聯(lián)網(wǎng)，當然這是不可能的。不過現(xiàn)實中稍微有點價值的網(wǎng)站基本上都可以支持各種oauth協(xié)議的單點登錄系統(tǒng)，所以能使用微博賬號、SNS賬號或者豆瓣賬號登陸的將會為用戶帶來更多的方便。對于企業(yè)來講，尤其是業(yè)務繁瑣復雜的大企業(yè)，單點登錄系統(tǒng)可以讓他們不必為每一個應用都開發(fā)用戶系統(tǒng)，從而大大降低了工作量，而且統(tǒng)一的用戶數(shù)據(jù)在后期管理和維護中也會更加方便。而基于oauth協(xié)議的單點登錄系統(tǒng)雖然開發(fā)成本高昂，但是能為企業(yè)帶來最具有價值的第一手用戶信息，其收益可觀。

單點登錄系統(tǒng)的基本流程

如上圖所示，不管是哪種方式的SSO系統(tǒng)其功能流程大概都是這樣：應用系統(tǒng)只需要調(diào)用SSO的驗證接口驗證當前用戶是否為已登錄用戶，如果是未登錄用戶或者嚴重不合法則跳轉到SSO系統(tǒng)。此時已注冊用戶可以直在SSO成功登錄后返回應用系統(tǒng)，應用系統(tǒng)開始重復上述步驟；而未注冊用戶則需要先注冊或者使用第三方SSO初始化賬號，繼而重復上述步驟。不同的是，賬號鏈接這樣的SSO系統(tǒng)在登陸成功后返回給應用系統(tǒng)一個key值、用戶uid和其他信息，而應用系統(tǒng)一般還是需要在自己的用戶系統(tǒng)中新建一個用戶賬戶并且建立一個映射關系來關聯(lián)SSO系統(tǒng)的返回值。如下圖所示是實現(xiàn)綁定微博賬號登陸的數(shù)據(jù)庫模型圖，其中應App_Users表可以實現(xiàn)一個用戶綁定多個單點登錄賬號，并且這樣的用戶是不需要再應用系統(tǒng)中存儲密碼等不必要的信息的。而Passport機制的SSO系統(tǒng)基本上處理所有用戶登錄、注冊、驗證的行為，其他應用系統(tǒng)只需要按需取用即可。

單點登錄系統(tǒng)開發(fā)難點
??????? 從上述功能流程可以看出，使用基于oauth協(xié)議的單點登錄系統(tǒng)應該是比較好的解決方案，但是沒有誰愿意把用戶的掌控權拱手讓給別人，所以國內(nèi)很多中小網(wǎng)站就算是沒有能力開發(fā)自己的passport單點登錄系統(tǒng)，也會去選擇UCenter這樣第三方開源的單點登錄系統(tǒng)。而Passport機制的單點登錄系統(tǒng)都會面臨這么一個問題，如何跨域傳遞cookies，至于為什么使用cookies、為什么要跨域這么啰嗦的廢話我就不多寫了，常用的跨域傳遞cookies的方法有三種：javascript/iframe、header和借助數(shù)據(jù)庫。javascript/iframe的思路是將單點登錄種下的cookie動態(tài)傳到應用系統(tǒng)，在ajax/jquery廣泛應用的時代javascript的是很常見的解決方案，例如UCenter的做法就是在單點登錄系統(tǒng)登陸后使用一段javascript動態(tài)把cookie傳遞到所有設置為同步登錄的應用，而iframe因為存在諸多弊端不建議使用。header的解決方法是使用P3P機制進行跨域傳輸,但是IE必須用加P3P的頭信息才可以跨域。看來IE對跨域的限制更為嚴格！所以要想實現(xiàn)完全跨域，在header頭里面加上這一句話最好： header('P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA div COM NAV OTC NOI DSP COR"'); 。不過在以前使用P3P協(xié)議開發(fā)單點登錄系統(tǒng)的時候或多或少都有些莫名其妙的問題，看來還是掌握的太少了。數(shù)據(jù)庫存儲，還是以Ucenter為例，在Discuz的cdb_sessions表就是一個結合session實現(xiàn)的跨域傳遞session的功能，只不過這樣的功能會給數(shù)據(jù)庫帶來嚴重的I/O負擔，但凡有點流量再碰上點極品的用戶這樣的數(shù)據(jù)庫性能肯定要被嚴重拖累。在我實際開發(fā)過程中，一般這樣解決單點登錄系統(tǒng)的跨域傳遞cookie問題：首先驗證用戶來源是否在我們的站點列表內(nèi)（如果是首先進入SSO則略去這一步），其次驗證用戶合法性，用戶通過驗證后，加密cookie和公用密鑰后的值將會在用戶登錄之后作為參數(shù)一起跳轉回來來源的應用系統(tǒng)，應用系統(tǒng)獲取到cookie值后調(diào)用SSO接口進行解密、驗證等工作。此外，還有一種比較簡略的SSO設計方案，所有SSO系統(tǒng)應有的功能都以API形式呈現(xiàn)，接受被授權的應用系統(tǒng)的請求并且返回相應的XML或者Json結果，不同的是，這樣做需要應用系統(tǒng)最起碼的有自己的登陸和注冊頁面，適用于同步不得不使用自己用戶功能的已經(jīng)成型的外部應用系統(tǒng)。此外，在上一篇文章中討論過的用戶密碼加密問題，由上圖也可以看出，pass字段存儲的應該是用戶真正的密碼經(jīng)過md5和加上salt值（隨機字符串）再次md5，也就是md5(md5(realpass).salt)，這個是程序猿應該知道的最基礎的加密方式。此外，很多人容易忽略的一個地方是cookie校驗，至少我親身體驗了京東修改完用戶密碼以前種下的cookie依然可以使用，F(xiàn)irebug看了下京東存儲的Cookie雖然是加密的，但是明顯的驗證cookie只是驗證了cookie是否為空或者是否可以解密，而完全沒有去驗證cookie用戶是否合法，這樣如果知道了京東的加密算法，即便是不知道用戶密碼，也可以偽造用戶cookie進入用戶賬戶。至于網(wǎng)上很多企業(yè)給出的SSO解決方案，我就不噴了，MD，如果真要用，UCenter或者簡單的使用新浪、騰訊、豆瓣的網(wǎng)站鏈接都不錯，雖然UCenter問題很多（這個以后再噴），但是最起碼的企業(yè)對用戶具有完全的掌控權。今天就扯這么多，才疏學淺，很多理論自認為有缺陷和不足，懇請指教。