多平臺的網站實現單點登陸系統(SSO)的開發思路 讓你的會員中心更加統一（參考資料）

單點登陸並非一個新鮮的玩意兒，比較官方的解釋是企業業務整合的解決方案之一，通俗來說SSO就是一個通用的用戶中心，國內比較流行的UCenter就是一套單點登陸解決方案。而近期以CSDN明文存儲用戶密碼並泄露用戶信息開始的各大網站爭先恐後的泄露本身的用戶數據庫除了暴露了這些網站的良心和智商外，如何設計用戶中心已成爲架構師們的熱點話題之一。在最近一兩年的項目經驗中有幸接觸到各類平臺的單點登陸系統的開發，因此藉此機會總結下B/S架構的單點登陸系統的開發經驗。

單點登陸系統的類別

就目前比較流行的應用來看，單點登陸系統主要分爲三種類型：一種是基於oauth協議的網絡令牌(我是這麼叫的)，一種是基於Web Service或者簡單Http協議實現的Passport機制，還有一種是以openid框架造成的通用帳號登陸機制。其中，基於oauth協議主要應用在網站外部，比較知名的有Google Account、Facebook Connect和新浪微博連接等；Passport的應用主要是針對同一網站內不一樣架構不一樣平臺，知名產品則更是數不勝數，例如Google Account帳號基本上能夠應用所有Google的網站，而國內各大門戶無數的應用系統也都只須要一個用戶通行證就能暢通無阻；至於OpenID這樣會共享用戶信息的應用，在國外可能會很火，在國內這樣一個用戶一寸金的利益集團面前可能會被採納，因此下面的論述也主要針對前面兩種。

單點登陸系統的優勢

對於用戶來說，最理想的狀況下一個帳號和密碼就能夠橫行整個互聯網，固然這是不可能的。不過現實中稍微有點價值的網站基本上均可以支持各類oauth協議的單點登陸系統，因此能使用微博帳號、SNS帳號或者豆瓣帳號登錄的將會爲用戶帶來更多的方便。

對於企業來說，尤爲是業務繁瑣複雜的大企業，單點登陸系統可讓他們沒必要爲每個應用都開發用戶系統，從而大大下降了工做量，並且統一的用戶數據在後期管理和維護中也會更加方便。而基於oauth協議的單點登陸系統雖然開發成本高昂，可是能爲企業帶來最具備價值的第一手用戶信息，其收益可觀。

單點登陸系統的基本流程

如上圖所示，不論是哪一種方式的SSO系統其功能流程大概都是這樣：應用系統只須要調用SSO的驗證接口驗證當前用戶是否爲已登陸用戶，若是是未登陸用戶或者嚴重不合法則跳轉到SSO系統。此時已註冊用戶能夠直在SSO成功登陸後返回應用系統，應用系統開始重複上述步驟；而未註冊用戶則須要先註冊或者使用第三方SSO初始化帳號，繼而重複上述步驟。

不一樣的是，帳號連接這樣的SSO系統在登錄成功後返回給應用系統一個key值、用戶uid和其餘信息，而應用系統通常仍是須要在本身的用戶系統中新建一個用戶帳戶而且創建一個映射關係來關聯SSO系統的返回值。以下圖所示是實現綁定微博帳號登錄的數據庫模型圖，其中應App_Users表能夠實現一個用戶綁定多個單點登陸帳號，而且這樣的用戶是不須要再應用系統中存儲密碼等沒必要要的信息的。而Passport機制的SSO系統基本上處理全部用戶登陸、註冊、驗證的行爲，其餘應用系統只須要按需取用便可。

單點登陸系統開發難點

從上述功能流程能夠看出，使用基於oauth協議的單點登陸系統應該是比較好的解決方案，可是沒有誰願意把用戶的掌控權拱手讓給別人，因此國內不少中小網站就算是沒有能力開發本身的passport單點登陸系統，也會去選擇UCenter這樣第三方開源的單點登陸系統。而Passport機制的單點登陸系統都會面臨這麼一個問題，如何跨域傳遞cookies，至於爲何使用cookies、爲何要跨域這麼囉嗦的廢話我就很少寫了，經常使用的跨域傳遞cookies的方法有三種：javascript/iframe、header和藉助數據庫。

javascript/iframe的思路是將單點登陸種下的cookie動態傳到應用系統，在ajax/jquery普遍應用的時代javascript的是很常見的解決方案，例如UCenter的作法就是在單點登陸系統登錄後使用一段javascript動態把cookie傳遞到全部設置爲同步登陸的應用，而iframe由於存在諸多弊端不建議使用。

header的解決方法是使用P3P機制進行跨域傳輸,可是IE必須用加P3P的頭信息才能夠跨域。看來IE對跨域的限制更爲嚴格！因此要想實現徹底跨域，在header頭裏面加上這一句話最好：header('P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA div COM NAV OTC NOI DSP COR"');。不過在之前使用P3P協議開發單點登陸系統的時候或多或少都有些莫名其妙的問題，看來仍是掌握的太少了。

數據庫存儲，仍是以Ucenter爲例，在Discuz的cdb_sessions表就是一個結合session實現的跨域傳遞session的功能，只不過這樣的功能會給數據庫帶來嚴重的I/O負擔，但凡是有點流量再碰上點極品的用戶這樣的數據庫性能確定要被嚴重拖累。

在我實際開發過程當中，通常這樣解決單點登陸系統的跨域傳遞cookie問題：首先驗證用戶來源是否在咱們的站點列表內（若是是首先進入SSO則略去這一步），其次驗證用戶合法性，用戶經過驗證後，加密cookie和公用密鑰後的值將會在用戶登陸以後做爲參數一塊兒跳轉回來來源的應用系統，應用系統獲取到cookie值後調用SSO接口進行解密、驗證等工做。此外，還有一種比較簡略的SSO設計方案，全部SSO系統應有的功能都以API形式呈現，接受被受權的應用系統的請求而且返回相應的XML或者Json結果，不一樣的是，這樣作須要應用系統最起碼的有本身的登錄和註冊頁面，適用於同步不得不使用本身用戶功能的已經成型的外部應用系統。

此外，在上一篇文章中討論過的用戶密碼加密問題，由上圖也能夠看出，pass字段存儲的應該是用戶真正的密碼通過md5和加上salt值（隨機字符串）再次md5，也就是md5(md5(realpass).salt)，這個是程序猿應該知道的最基礎的加密方式。此外，不少人容易忽略的一個地方是cookie校驗，至少我親身體驗了京東修改完用戶密碼之前種下的cookie依然可使用，Firebug看了下京東存儲的Cookie雖然是加密的，可是明顯的驗證cookie只是驗證了cookie是否爲空或者是否能夠解密，而徹底沒有去驗證cookie用戶是否合法，這樣若是知道了京東的加密算法，即使是不知道用戶密碼，也能夠僞造用戶cookie進入用戶帳戶。

至於網上不少企業給出的SSO解決方案，我就不噴了，MD，若是真要用，UCenter或者簡單的使用新浪、騰訊、豆瓣的網站連接都不錯，雖然UCenter問題不少（這個之後再噴），可是最起碼的企業對用戶具備徹底的掌控權。

http://www.itokit.com/2012/0523/74123.html