1. 程式人生 > >SSO單點登入的幾種方式

SSO單點登入的幾種方式

簡介

單點登入SSO(Single Sign On)是在一個多系統共存的環境下,使用者在一處登入之後,就不用在其他的系統中登入,也就是使用者的一次登入能得到其他所有系統的信任.單點登入在大型網站裡面使用的比較多,例如像阿里巴巴這樣的網站,在萬丈的背後是成百上千的子系統,使用者一次操作或交易可能涉及到幾個十幾個子系統的協作,如果每個子系統都需要使用者認證,會在無形中增加時間的耗費.實現單點登入說到底就是要解決如何產生和儲存那個信任,再就是其他子系統如何驗證這個信任的有效性,因此要一下兩個點:

·儲存信任

·驗證信任

--第一種:以Cookie作為憑證媒介

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

從上面的圖我們可以發現,把信任儲存在客戶端的cookie中,這種方式很容易讓人質疑,

--cooki不安全

--不能跨域實現免登

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

--第二種:通過JSONP實現

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

--這種方式雖然能解決蛞蝓問題,但是安全性其實跟把信任儲存到cookie是差不多的,如果一旦加密演算法洩露了,攻擊者可以在本地建立一個實現了登入介面的假冒父應用,通過繫結Host來把子應用發起的請求指向本地的假冒父應用,並作出迴應.

--因為攻擊者完全可以按照加密演算法來偽造響應請求,子應用接收到這個響應之後可以通過驗證,並且登入特定使用者.

第三種:通過頁面重定向的方式

最後一種是,通過父應用和子應用來回重定向中進行同行,實現資訊的安全傳遞.

父應用提供一個GET方式的登入介面,使用者通過子應用重定向連線的這個方式的訪問這個介面,如果使用者還沒有登入,則返回一個的登入頁面,使用者輸入賬號密碼進行登入,如果使用者已經登入,則生成加密的Token,並且重定向到子應用提供的token的介面,通過解密和校驗之後,子應用登陸當前使用者.

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

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