單點登入sso（single sign on）說得簡單點就是在乙個多系統共存的環境下，使用者在一處登入後，就不用在其他系統中登入，也就是使用者的一次登入能得到其他所有系統的信任。單點登入在大型**裡使用得非常頻繁，例如像阿里巴巴這樣的**，在**的背後是成百上千的子系統，使用者一次操作或交易可能涉及到幾十個子系統的協作，如果每個子系統都需要使用者認證，不僅使用者會瘋掉，各子系統也會為這種重複認證授權的邏輯搞瘋掉。實現單點登入說到底就是要解決如何產生和儲存那個信任，再就是其他系統如何驗證這個信任的有效性，因此要點也就以下兩個：
儲存信任
驗證信任
如果乙個系統做到了開頭所講的效果，也就算單點登入，單點登入有不同的實現方式，本文就羅列我開發中所遇見過的實現方式。
最簡單的單點登入實現方式，是使用cookie作為媒介，存放使用者憑證。 使用者登入父應用之後，應用返回乙個加密的cookie，當使用者訪問子應用的時候，攜帶上這個cookie，授權應用解密cookie並進行校驗，校驗通過則登入當前使用者。這種方式把信任儲存在客戶端的cookie中，這種方式很容易令人質疑：
對於第乙個問題，通過加密cookie可以保證安全性，當然這是在源**不洩露的前提下。如果cookie的加密演算法洩露，攻擊者通過偽造cookie則可以偽造特定使用者身份，這是很危險的。 對於第二個問題，更是硬傷。
通過jsonp實現
對於跨域問題，可以使用jsonp實現。 使用者在父應用中登入後，跟session匹配的cookie會存到客戶端中，當使用者需要登入子應用的時候，授權應用訪問父應用提供的jsonp介面，並在請求中帶上父應用網域名稱下的cookie，父應用接收到請求，驗證使用者的登入狀態，返回加密的資訊，子應用通過解析返回來的加密資訊來驗證使用者，如果通過驗證則登入使用者。
這種方式雖然能解決跨域問題，但是安全性其實跟把信任儲存到cookie是差不多的。如果一旦加密演算法洩露了，攻擊者可以在本地建立乙個實現了登入介面的假冒父應用，通過繫結host來把子應用發起的請求指向本地的假冒父應用，並作出回應。 因為攻擊者完全可以按照加密演算法來偽造響應請求，子應用接收到這個響應之後一樣可以通過驗證，並且登入特定使用者。
最後一種介紹的方式，是通過父應用和子應用來回重定向中進行通訊，實現資訊的安全傳遞。 父應用提供乙個get方式的登入介面，使用者通過子應用重定向連線的方式訪問這個介面，如果使用者還沒有登入，則返回乙個的登入頁面，使用者輸入賬號密碼進行登入。如果使用者已經登入了，則生成加密的token，並且重定向到子應用提供的驗證token的介面，通過解密和校驗之後，子應用登入當前使用者。
這種方式較前面兩種方式，接解決了上面兩種方法暴露出來的安全性問題和跨域的問題，但是並沒有前面兩種方式方便。 安全與方便，本來就是一對矛盾。
一般說來，大型應用會把授權的邏輯與使用者資訊的相關邏輯獨立成乙個應用，稱為使用者中心。 使用者中心不處理業務邏輯，只是處理使用者資訊的管理以及授權給第三方應用。第三方應用需要登入的時候，則把使用者的登入請求**給使用者中心進行處理，使用者處理完畢返回憑證，第三方應用驗證憑證，通過後就登入使用者。
此文章**於：
單點登入的三種實現方式
宣告 此文 自jc huang 單點登入sso single sign on 說得簡單點就是在乙個多系統共存的環境下，使用者在一處登入後，就不用在其他系統中登入，也就是使用者的一次登入能得到其他所有系統的信任。單點登入在大型 裡使用得非常頻繁，例如像阿里巴巴這樣的 在 的背後是成百上千的子系統，使用...
單點登入的三種實現方式
cookie 的作用域由 domain 屬性和 path 屬性共同決定。domain 屬性的有效值為當前域或其父域的網域名稱 ip位址，在 tomcat 中，domain 屬性預設為當前域的網域名稱 ip位址。path 屬性的有效值是以 開頭的路徑，在 tomcat 中，path 屬性預設為當前 w...
JWT單點登入的三種解決方案
1.純jwt 2.jwt 認證中心redis 3.jwt 認證中心redis 多系統redis1.純jwt 方案1.使用者去認證中心登入，認證中心生成jwt，返回給客戶端。2.客戶端攜帶jwt請求多個系統 3.每個系統各自解析jwt，取出使用者資訊。能解析成功就說明jwt有效，繼續處理自己的業務邏輯...