序文
プログラムで主流の技術に関する市場でのSSO：
- SpringSecurity +のOAuth2
- SpringSecurity + CAS機能は、フロントとリアエンドプロジェクト支援の分離は非常に良いではない、弱いです
- Shiro + CAS
- JWTは、需要、柔軟な拡張認証モードをカスタマイズすることができます
この章のデータは、シングルサインオン、認証が関与していないで、後の記事でちょうど追加されます
XXL-SSOが実現クッキーに基づいて、国内のSSOのフレームワークであり、あなたはそれ自体、クロスドメインのクッキーが、クロスドメインの問題を検討するかもしれないが、あなたは、クロスドメインSSOを実現するためにそれを使用することができます。
1.公式のサンプルプロジェクトを引い
gitee住所：HTTPS：//gitee.com/xuxueli0323/xxl-sso
GitHubのアドレスします。https：//github.com/xuxueli/xxl-sso
モジュール説明：
- XXL-SSOサーバ：中央認証サービス、サポート・クラスター
- XXL-SSO-コア：クライアント側の依存関係
- XXL-SSO-サンプル：シングルサインクライアントの典型的なアクセス端末プロジェクト
- XXL-SSO-ウェブサンプルspringboot：ユーザーのブラウザにアクセスするためのCookieベースのアクセス、springbootバージョン
- XXL-SSOトークン-サンプルspringboot：トークンベースのアクセスは、このようなAPP、クッキーなどが無効になっている、springboot版として使用するクッキーのシナリオで一般的に使用することはできません
環境によって異なります。
JDK：1.7以上
のRedis：4.0+
ローカルホストの変更：
127.0.0.1 xxlssoserver.com
127.0.0.1 xxlssoclient1.com
127.0.0.1 xxlssoclient2.com
プロジェクトをインポートした後開始しました：
application.propertiesのRedisのは、ローカルアドレスの後にXXL-SSOサーバを起動し変更します。
### xxl-sso
xxl.sso.redis.address=redis://127.0.0.1:6378
xxl.sso.redis.expire.minite=1440
パスワードを設定して、あなたがマップ上で私に似ている場合は完璧なエラー、あなたのRedisを述べ、公式のサンプルコードは、パスワードのRedis設定されていない、コンソールを参照してください。
私たちは、ローカルアドレスのRedisを初期化するために使用された場合、その後、ちょうどこのアドレスが使用されている場所で、その後、確かにパスワードを設定する場所があるだろう知っている必要があることがわかります。
果不其然，我们最终发现了，地址是通过 JedisShardInfo 这个对象传递进去的，进入这个对象后发现，竟然有个 password？这不就是我们要找的密码吗。
再次启动，成功启动。
同样的修改 xxl-sso-samples > xxl-sso-web-samples-sprigboot 的 properties 然后再启动。
2、认证流程
客户端端口号被我改成8085，认证中心保持默认端口号8080
届时，我们启动了两个项目，浏览器访问第一个域名：http://xxlssoclient1.com:8085/xxl-sso-web-sample-springboot
我们可以看到访问后将被重定向到认证中心 http://xxlssoserver.com:8080/xxl-sso-server ，后面携带参数 redirect_url ，其为界面跳转前的链接，认证通过后将再次重定向回原来的访问链接。
上图为认证成功后的图片，会携带 xxl_sso_sessionid，其用于识别用户登陆信息，并会保存至本地两份 cookie，皆用来保存 xxl_sso_sessionid ，一份当前域名(xxlssoclient1.com)，一份认证中心(xxlssoserver.com)。
保存的两份 xxl_sso_sessionid 值是一样的。
xxl_sso_sessionid由来
在上图中的认证界面，点击登录后会调用 WebController > doLogin 方法，用户登录成功后会生成该用户的 xxl_sso_sessionid 信息，并保存至 redis 中，同时会把 xxl_sso_sessionid 写入客户端 cookie，然后将重定向到 redirect_url，并拼接 xxl_sso_sessionid 参数，如下图所示。
我们再来访问第二个客户端试试，http://xxlssoclient2.com:8085/xxl-sso-web-sample-springboot，就目前并未向 http://xxlssoclient2.com:8085 写入任何有关 cookie 用户会话信息：
神奇的一幕发生了，显然2号客户端也成功登陆了，并携带了跟客户端1一样的 xxl_sso_sessionid 信息，我们再来看一下 cookie 信息：
xxlssoclient2.com中的xxl_sso_sessionid哪里来的？
其实通过 debug 发现，在 xxlssoclient1.com 登陆的前提下，再去访问 xxlssoclient2.com 时，由于没有任何登陆信息同样也是首先会跳转至认证中心：
还记得客户端1登陆后在认证中心 xxlssoserver.com 同样留下 xxl_sso_sessionid 信息吗？
显然，客户端2号再跳转过来时复用了认证中心的 xxl_sso_sessionid，然后发现存在 xxl_sso_sessionid，且 xxl_sso_sessionid 在 redis 里也没过期，则认为用户已经登陆了，重新重定向到 xxlssoclient2.com
退出操作
看完了统一登录，再来看一下退出操作。
退出相对就比较简单了，主要就是验证 redis 中的 xxl_sso_sessionid，我们来看一下退出方法：
首先调用退出方法后会清空当前网站的 cookie、redis 中的 xxl_sso_sessionid，比如在 xxlssoclient1.com、xxlssoclient2.com 都登陆的情况下，通过 xxlssoclient2.com 退出当前用户，则首先会清空 xxlssoclient2.com 站点下的 cookie ，同时后台也会清空当前用户的 redis，那么再通过 xxlssoclient1.com 访问时，尽管携带 xxl_sso_sessionid，但此时该信息已经过期，所以会再次重定向认证中心。
xxl-sso小结
如上为 xxl-sso 架构图，其核心为：
sso-server：中央认证服务
sso-client：接入 sso 认证中心的客户端应用
sso-sessionId：登陆用户会话ID，SSO 登陆成功后为用户自动分配
sso-user：登陆用户信息，与 SSO sessionId 相对应
登陆流程剖析：
- 客户端访问受限资源时，将会自动重定向到 SSO Server 进入统一登录界面
- 用户登录成功之后将会为用户分配 SSO SessionId 并重定向返回来源客户端端应用，同时附带分配的 SSO SessionId
- 在客户端的 SSO 过滤器里验证 SSO SessionId 无误，将 SSO SessionId 写入到用户浏览器客户端域名下 cookie 中
- SSO 过滤器验证 SSO SessionId 通过，受限资源请求放行
注销流程剖析：
- 用户在客户端应用请求注销时，将会重定向到 SSO Server 自动销毁全局 SSO SessionId，实现全局销毁用户登陆信息；
- 然后，访问接入SSO 保护的任意客户端应用时，SSO 过滤器均会拦截请求并重定向到 SSO Server 的统一登录界面；
至此，通过 cookie+redis 解决了多端统一认证，全局 sessionId 解决了 session 共享的问题。
基于Cookie，相关概念
- 登陆凭证存储：登陆成功后，用户登陆凭证被自动存储在浏览器Cookie中
- 客户端校验登陆状态：通过校验请求Cookie中的是否包含用户登录凭证判断
- 系统角色模型：
-- SSO Server：认证中心，提供用户登陆、注销以及登陆状态校验等功能
-- 客户端应用：受SSO保护的客户端Web应用，为用户浏览器访问提供服务
-- 用户：发起请求的用户，使用浏览器访问
如果 Cookie 被禁用怎么办？
xxl-sso 同样提供了 基于 token 接入方式，用于无法使用Cookie的场景使用，如APP、Cookie被禁用等，详细可参考 xxl-sso-token-sample-springboot 项目。
基于Token，相关概念
- 登陆凭证存储：登陆成功后，获取到登录凭证（xxl_sso_sessionid=xxx），需要主动存储，如存储在 localStorage、Sqlite 中
- 客户端校验登陆状态：通过校验请求 Header参数 中的是否包含用户登录凭证（xxl_sso_sessionid=xxx）判断；因此，发送请求时需要在 Header 参数 中设置登陆凭证
- 系统角色模型：
-- SSO Server：认证中心，提供用户登陆、注销以及登陆状态校验等功能
--客户端应用：受SSO保护的客户端Web应用，为用户请求提供接口服务
-- 用户：发起请求的用户，如使用Android、IOS、桌面客户端等请求访问
更多信息请访问官方文档：http://www.xuxueli.com/xxl-sso/#/
后面会写一篇实际项目中接入 xxl-sso 框架的实例。
我创建了一个java相关的公众号，用来记录自己的学习之路，感兴趣的小伙伴可以关注一下微信公众号哈：niceyoo
