1. 程式人生 > >單點登入的三種實現方式

單點登入的三種實現方式

單點登入SSO(Single Sign On)說得簡單點就是在一個多系統共存的環境下,使用者在一處登入後,就不用在其他系統中登入,也就是使用者的一次登入能得到其他所有系統的信任。單點登入在大型網站裡使用得非常頻繁,例如像阿里巴巴這樣的網站,在網站的背後是成百上千的子系統,使用者一次操作或交易可能涉及到幾十個子系統的協作,如果每個子系統都需要使用者認證,不僅使用者會瘋掉,各子系統也會為這種重複認證授權的邏輯搞瘋掉。實現單點登入說到底就是要解決如何產生和儲存那個信任,再就是其他系統如何驗證這個信任的有效性,因此要點也就以下兩個:

  • 儲存信任
  • 驗證信任

如果一個系統做到了開頭所講的效果,也就算單點登入,單點登入有不同的實現方式,本文就羅列我開發中所遇見過的實現方式。

以Cookie作為憑證媒介

最簡單的單點登入實現方式,是使用cookie作為媒介,存放使用者憑證。使用者登入父應用之後,應用返回一個加密的cookie,當用戶訪問子應用的時候,攜帶上這個cookie,授權應用解密cookie並進行校驗,校驗通過則登入當前使用者。

Auth via cookie

不難發現以上方式把信任儲存在客戶端的Cookie中,這種方式很容易令人質疑:

  • Cookie不安全
  • 不能跨域實現免登

對於第一個問題,通過加密Cookie可以保證安全性,當然這是在原始碼不洩露的前提下。如果Cookie的加密演算法洩露,攻擊者通過偽造Cookie則可以偽造特定使用者身份,這是很危險的。對於第二個問題,更是硬傷。

通過JSONP實現

對於跨域問題,可以使用JSONP實現。使用者在父應用中登入後,跟Session匹配的Cookie會存到客戶端中,當用戶需要登入子應用的時候,授權應用訪問父應用提供的JSONP介面,並在請求中帶上父應用域名下的Cookie,父應用接收到請求,驗證使用者的登入狀態,返回加密的資訊,子應用通過解析返回來的加密資訊來驗證使用者,如果通過驗證則登入使用者。

Auth via jsonp

這種方式雖然能解決跨域問題,但是安全性其實跟把信任儲存到Cookie是差不多的。如果一旦加密演算法洩露了,攻擊者可以在本地建立一個實現了登入介面的假冒父應用,通過繫結Host來把子應用發起的請求指向本地的假冒父應用,並作出迴應。因為攻擊者完全可以按照加密演算法來偽造響應請求,子應用接收到這個響應之後一樣可以通過驗證,並且登入特定使用者。

通過頁面重定向的方式

最後一種介紹的方式,是通過父應用和子應用來回重定向中進行通訊,實現資訊的安全傳遞。父應用提供一個GET方式的登入介面,使用者通過子應用重定向連線的方式訪問這個介面,如果使用者還沒有登入,則返回一個的登入頁面,使用者輸入賬號密碼進行登入。如果使用者已經登入了,則生成加密的Token,並且重定向到子應用提供的驗證Token的介面,通過解密和校驗之後,子應用登入當前使用者。

Auth via redirect

這種方式較前面兩種方式,接解決了上面兩種方法暴露出來的安全性問題和跨域的問題,但是並沒有前面兩種方式方便。安全與方便,本來就是一對矛盾。

使用獨立登入系統

一般說來,大型應用會把授權的邏輯與使用者資訊的相關邏輯獨立成一個應用,稱為使用者中心。使用者中心不處理業務邏輯,只是處理使用者資訊的管理以及授權給第三方應用。第三方應用需要登入的時候,則把使用者的登入請求轉發給使用者中心進行處理,使用者處理完畢返回憑證,第三方應用驗證憑證,通過後就登入使用者。