SSO单点登录

系统架构演变

1. 单体架构

用户量很少的时候，一台服务器就能搞定需要承载的用户量。这个时候我们完全只需要将登录信息存在session中就好。

2. 负载均衡

随着用户量的提升，我们会使用nginx进行负载均衡，这样就会发现session本来是存在某一台服务器的，不能在不同的服务器共享。这个时候，我们就能使用redis-session技术把session信息存入redis从而达到不同服务器session信息的共享。

3. 垂直切分/分布式/SOA（服务治理）/微服务架构

不管是垂直切分服务，还是分布式、SOA、微服务架构，这个如果仅仅只是把一个系统的不同的职能拆分，那么还是可以像负载均衡的那样把用户登录的信息存到一个像redis内存数据库的地方。然后返回客户端一个token就好。
注意的是，这个登录服务、和验证是否登录、获取用户信息、都是属于拆分服务"用户服务"中的。其他服务验证是否登录和验证都需要调用“用户服务”

4. 具有多个域名的系统。

一个token换了域名前端就不能存了，这个时候我们很容易就能想到JSONP，可以使用JSONP把授权token信息传入被调服务。

单点登录的实现工具

支持单点登录的系统角色

首先要搞清楚单点登录中各个服务的角色：

sso-client（用户服务之外的其他服务）

• 拦截子系统未登录用户请求，跳转至sso认证中心
• 接收并存储sso认证中心发送的令牌
• 与sso-server通信，校验令牌的有效性
• 建立局部会话
• 拦截用户注销请求，向sso认证中心发送注销请求
• 接收sso认证中心发出的注销请求，销毁局部会话

sso-server（用户服务）

• 验证用户的登录信息
• 创建全局会话
• 创建授权令牌
• 与sso-client通信发送令牌
• 校验sso-client令牌有效性
• 系统注册
• 接收sso-client注销请求，注销所有会话

实现SSO的技术

技术整合，Redis

实际上就是把key的token 用户信息为value的键值对存入redis，设置过期时间，验证是否登录，获取用户信息都用王redis去取。

优点：
过期策略可以直接使用redis的过期策略、

缺点：稳定性需要得到考量，一旦redis挂了，所有需要验证登录信息的都会不能访问

JWT（JSON Web Token）

直接把用户信息放入一串JSON字符串中，每次请求的时候可以放入http头部，url，或者请求体中，每个子系统验证是否登录的时候直接把token信息解密然后就能获取相应的信息了

过期信息在哪？也在Token里，在请求时，前置判断token是否过期就可以了。

怎么跳转登录呢 ：
如系统A 系统B 和用户系统C，
假设：

1. 我要访问A的某一个服务/some/getAXXX，没有登录，
2. 那么系统A会返回302，让浏览器重定向C的登录页，然后用户登录，C系统签发一个token， 然后返回浏览器302 让浏览器带着签发的token，重定向到A服务的/some/getAXXX。
3. A服务的/some/getAXXX接收到token，验证token的有效性。继续服务。

优点：
不需要redis存储。

缺点：
请求时会带一长串加密字符，传输的数据包很大。