關於SSO一直沒有深入的研究，在工作中也是對接的公司平臺的SSO，最近頻繁的與SSO打交道之後，我決定深入的理解一下它的實現原理；
一.SSO的實現種類
SSO系統在公司一般是獨立部署的一套系統，需要各業務系統接入，回想一下之前傳統系統都是業務+登錄一體化，那個時候，我們可以將用戶信息保存到session，那如果是微服務+獨立SSO該怎麼實現各系統session共享的問題?
1.基於共享session
我們都知道每臺服務的session是互相不共享的，假設將我們的 商品服務、訂單服務等服務的session都共享，就可以實現一處登錄，全站訪問的特點；
實現共享session的方式不是本文的重點，它存在一定的缺陷，就是所有的服務器都必須保持一致，不能說有些服務是tomcat，有些是jetty；
提升一種思路就是通過 Spring Session 或者 tomcat-redis-session-manager
2.基於認證中心
這種方案需要自己實現一套SSO或使用第三方的，所有系統的認證操作都是在這個系統中完成的，它管理着整個用戶的狀態，這種實現方式需要SSO系統提供有登錄、註冊等操作的前端頁面。下面重點介紹下實現方式；
二.實現方式
我們模擬三個服務：
系統A：a.demo.com
系統B：b.demo.com
SSO：sso.demo.com
1.登錄流程
關鍵點：
1.它用到了兩個cookie(sid與token)和三次重定向；
2.token是寫到a.demo.com域名下的，sid是寫到sso.demo.com域名下的；
3.在驗證token的時候，如何知道當前用戶已經創建了全局會話？因爲jwt的payload裏面存儲了之前創建sso的會話sid，所以當cas拿到jwt，就相當於知道了sid；
注意：
SSO服務如果是集羣部署的，則需要解決sid共享問題；
2.訪問系統B的頁面
在這個過程中關鍵在於第一次重定向的時候，它會把sso.demo.com這個域名下的sid帶給sso服務；
3.退出
最重要的是要清除sid的cookie，jwt的cookie可能業務系統都有創建，所以不可能在退出的時候還挨個去清除，只要sid一清除，那麼即使那些jwt的cookie在下次訪問的時候還會被傳遞到業務系統有服務端；
三.總結
在真實的項目中，可能需要考慮到更多的安全性的要求，比如：
1.使用https
2.http-only
3.CSRF
總的來說，優缺點主要有：
1.能夠支持跨平臺，跨語言實現單點登錄；
2.重寫向次數過多；
3.每次請求都需要調用SSO驗證token有效性；