发展历史
1.单体应用
基于tomcat的session机制，而tomcat的session机制本质上是基于客户端和服务器的Cookie技术(即包含JSESSIONID=XXX)实现的。如果客户端禁用Cookie怎么办？把以前的Cookie(JSESSIONID=XXX)，显式的写在每个请求url后面。
2.集群/集成系统
因为session只在一个节点起作用，所以想要多个系统只需要登录一次无需登录多次，就要有一个统一的地方集中保存数据。
禁用Cookie，怎么实现session？
显式添加会话id字段到每个请求url。
首先，我们想一下，会话id是从哪里来的？客户端第一次请求服务器时，服务器响应的数据包含会话id，以后每次请求输入即可。这样就有了会话功能。
由此可知，本质上，会话id只是一个请求参数字段而已，和其他的请求参数字段没有任何不同，只不过这个字段的值最开始是由服务器返回的，且每个用户不同。
现在客户端默认的Cookie技术被禁用了，就只能想办法把这个参数照样像以前那样传递给服务器，以前是基于浏览器客户端的默认Cookie技术，现在需要程序员自己想办法实现。具体怎么实现呢？有两种办法。
1.一种是显式的直接拼接到url后面 //最佳实践
2.一种是form的隐藏字段
这两种解决方法，也就是所谓的重写url，其实就是在每个请求url后面显式加上会话id字段参数。
blog.csdn.net/u014225431/… segmentfault.com/q/101000000…
架构图
四、部署图
单点登录涉及sso认证中心与众子系统，子系统与sso认证中心需要通信以交换令牌、校验令牌及发起注销请求，因而子系统必须集成sso的客户端，sso认证中心则是sso服务端，整个单点登录过程实质是sso客户端与服务端通信的过程，用下图描述
sso认证中心与sso客户端通信方式有多种，这里以简单好用的httpClient为例，web service、rpc、restful api都可以
总结
1.节点之间的通信
就是子系统和sso的通信，其实就是客户端(有sso-client.jar)和服务器(sso.war)的通信。
2.sso其实就是web项目，部署在tomcat的war包
原理
登陆验证次数
1.sso
2.子系统
sso只需要登陆验证第一次请求，后面的请求就不需要经过sso，而是直接经过子系统认证即可。
全局会话和局部会话
1.sso
全局会话
2.子系统
局部会话
sso和子系统是如何通信的？
通过令牌token。
用户登录成功之后，会与sso认证中心及各个子系统建立会话，用户与sso认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过sso认证中心，全局会话与局部会话有如下约束关系：
局部会话存在，全局会话一定存在
全局会话存在，局部会话不一定存在
全局会话销毁，局部会话必须销毁
你可以通过博客园、百度、csdn、淘宝等网站的登录过程加深对单点登录的理解，注意观察登录过程中的跳转url与参数
注销步骤
1.sso注销，即全局会话注销
2.所有子系统注销，即局部会话注销
协议OAuth2.0
发展历史
1.1.0
2.2.0 //2.0是升级版，但是不兼容1.0
几个角色
四大角色
由授权流程图中可以看到 OAuth 2.0 有四个角色：客户端、资源拥有者、资源服务器、授权服务器。
客户端：客户端是代表资源所有者对资源服务器发出访问受保护资源请求的应用程序。 资源拥有者：资源拥有者是对资源具有授权能力的人。 资源服务器：资源所在的服务器。 授权服务器：为客户端应用程序提供不同的
Token，可以和资源服务器在统一服务器上，也可以独立出去。
二、名词定义
在详细讲解OAuth 2.0之前，需要了解几个专用名词。它们对读懂后面的讲解，尤其是几张图，至关重要。
（1） Third-party application：第三方应用程序，本文中又称"客户端"（client），即上一节例子中的"云冲印"。
（2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上一节例子中的Google。
（3）Resource Owner：资源所有者，本文中又称"用户"（user）。
（4）User Agent：用户代理，本文中就是指浏览器。
（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
知道了上面这些名词，就不难理解，OAuth的作用就是让"客户端"安全可控地获取"用户"的授权，与"服务商提供商"进行互动。
几种模式
客户端的授权模式
客户端必须得到用户的授权（Authorization Grant），才能获得令牌（access token）。OAuth 2.0 定义了四种授权方式：authorizationcode(授权码)、implicit(简单)、resource owner password credentials(密码)、client credentials(客户端)。
1.授权码模式 //适合有前后台
授权码 + 令牌token
2.简化模式 //适合只有前端没有后台
3.用户名密码模式 //适合高度信任，一般比较少用，因为用户名密码是绝对机密
https://oauth.b.com/token?
grant_type=password&
username=USERNAME& //包含用户名密码
password=PASSWORD&
client_id=CLIENT_ID
4.客户端凭证模式 //适合没有客户端的命令行
https://oauth.b.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
代码实现
www.ruanyifeng.com/blog/2019/0…
实现非常简单，其实就是第一种模式-授权码+令牌token模式，步骤如下：
1.获取和响应授权码
2.获取和响应token
sso和OAuth2.0的关系？
一个是协议，一个是对协议的实现。sso是对OAuth2.0协议的一种实现。
那sso是实现四种模式的哪一种？ 第一种模式-授权码模式：授权码 + 令牌token
第三方登陆和OAuth2.0的关系？
第三方登陆也是对OAuth2.0协议的一种实现。
参考
www.ruanyifeng.com/blog/2014/0… //大概的介绍 www.ruanyifeng.com/blog/2019/0… //类比小区的门禁系统，更容易理解token的作用(就是短期有效密码)
www.ruanyifeng.com/blog/2019/0… //四种模式
代码实现
单点登录sso和分布式session的区别？
这两个问题是不同的问题
1.sso
解决的是登陆验证用户名密码的问题。集成系统必须提供一个统一的登陆验证中心。
2.session
是登陆成功之后的问题，就是如何保存和维持session的问题。分布式session就是在一个集中系统(缓存中间件redis)存储session数据。
这两个问题发生的时间节点都不一样。也是不同的两个问题。
工作使用
支付系统
没有实现sso，因为各个系统是独立的，且域名不同，所以各个系统都是独立的用户系统。另外，是很晚的时候才开始要做sso。
即时通讯
和门户集成，所以肯定是必须要实现单点登录系统的。
政府项目
集成很多项目，按理来说也是应该要实现sso的。
第三方登陆
其实也是sso，只不过是使用的第三方作为sso，而不是自己实现的，没有自己的用户系统。所以，一般情况下，都是使用第三方和本地系统用户进行绑定的方式，而不是仅仅只是使用第三方登陆，这样的话既可以第三方登陆的方便又可以沉淀自己的用户系统。
参考
www.cnblogs.com/study-every… //写的非常，基本上一篇文章看懂
www.jianshu.com/p/f5f9196f3… //京东、淘宝都是实现自己的sso
