Single Sign On 一处登陆、处处可用
0、前置概念：
1）、单点登录业务介绍
早期单一服务器，用户认证。
缺点：单点性能压力，无法扩展 分布式，
SSO(single sign on)模式
解决 ：
用户身份信息独立管理，更好的分布式管理。
可以自己扩展安全策略
跨域不是问题
缺点：
认证服务器访问压力较大。
2）、几个基本概念
2.1 什么是跨域 Web SSO
域名通过“.”号切分后，从右往左看，不包含“.”的是顶级域名，包含一个“.”的是一级域名， 包含两个“.”的是二级域名，以此类推。
例如对网址 http://www.cnblogs.com/baibaomen，域名部分是 www.cnblogs.com。 用“.”拆分后从右往左看：
cookie.setDomain(“.cnblogs.com”);//最多设置到本域的一级域名这里
cookie.setDomain(“.baidu.com”);//最多设置到本域的一级域名这里
”com”不包含“.”，是顶级域名； “cnblogs.com”包含一个“.”，是一级域名；
www.cnblogs.com 包含两个“.”，是二级域名。
blog.cnblogs.com
news.cnblogs.com
跨域 Web SSO 指的是针对 Web 站点，各级域名不同都能处理的单点登录方案。
2.2 浏览器读写 cookie 的安全性限制
浏览器读写 cookie 的安全性限制：一级或顶级域名不同的网站， 无法读到彼此写的 cookie。
所以 baidu.com 无法读到 cnblogs.com 写的 cookie。 一级域名相同，只是二级或更高级域名不同的站点，可以通过设置 domain 参数共享 cookie
读写。这种场景可以选择不跨域的 SSO 方案。 域名相同，只是 https 和 http 协议不同的 URL，默认 cookie 可以共享。知道这一点对处 理 SSO 服务中心要登出
2.3 http 协议是无状态协议
浏览器访问服务器时，要让服务器知道 你是谁，只有两种方式：
方式一：把“你是谁”写入 cookie。它会随每次 HTTP 请求带到服务端；
方式二：在 URL、表单数据中带上你的用户信息（也可能在 HTTP 头部）。这种方式依赖 于从特定的网页入口进入，因为只有走特定的入口，才有机会拼装出相应的信息，提交到服 务端。
大部分 SSO 需求都希望不依赖特定的网页入口（集成门户除外），所以后一种方式有局限 性。适应性强的方式是第一种，即在浏览器通过 cookie 保存用户信息相关凭据，随每次请 求传递到服务端。我们采用的方案是第一种。
1、Cookie 接入方式
2、Token 接入方式
类似社交登陆
3、有状态登录
为了保证客户端 cookie 的安全性，服务端需要记录每次会话的客户端信息，从而识别客户 端身份，根据用户身份进行请求的处理，典型的设计如 tomcat 中的 session。
例如登录：用户登录后，我们把登录者的信息保存在服务端session中，并且给用户一个cookie值，记录对应的 session。然后下次请求，用户携带 cookie 值来，我们就能识别到对应 session， 从而找到用户的信息。
缺点是什么？
- 服务端保存大量数据，增加服务端压力
- 服务端保存用户状态，无法进行水平扩展
- 客户端请求依赖服务端，多次请求必须访问同一台服务器
即使使用 redis 保存用户的信息，也会损耗服务器资源。
4、无状态登录
微服务集群中的每个服务，对外提供的都是 Rest 风格的接口。而 Rest 风格的一个最重要的 规范就是：服务的无状态性，即：
- 服务端不保存任何客户端请求者信息
- 客户端的每次请求必须具备自描述信息，通过这些信息识别客户端身份 带来的好处是什么呢？
- 客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同一台服务
- 服务端的集群和状态对客户端透明
- 服务端可以任意的迁移和伸缩
- 减小服务端存储压力
5、集成社交登陆
1）、用户点击不同的社交登陆按钮，先来我们自己的服务器
https://passport.csdn.net/v1/register/authorization?authType=qq /sina
2）、命令浏览器重定向到用户授权页
用户确认授权
https://graph.qq.com/oauth2.0/authorize
3）、qq 返回的响应，会命令用户重定向到指定位置
4）、服务器的这个位置就可以收到我们的 code 码
收到 code 码，服务器自己用 code 交换 access_token 令牌，并获取到用户的信息。给浏览器 只给用户的信息即可；
access_token=UUID
浏览器访问带 UUID_token 而不是 access_token；
