本着由简如繁的逻辑，在说单点登录之前，咱们先介绍一下简单的单系统登录

简单的单系统登录机制

主要基于两个问题来介绍：

这个原因就比较多了，不同的系统有不同的逻辑，简单罗列2个，比如：1.权限限制，最常见的就是一个后台系统，会根据不同的登录角色，展示不同的菜单操作项2.需要保存用户的信息，最常见的就是收藏、支付订单等

大家知道，http是一种无状态协议，什么是无状态协议呢，看下面这个图：

无状态是指,当浏览器给服务器发送请求的时候,服务器响应客户端请求。但是当同一个浏览器再次发送请求给服务器的时候,服务器并不知道他就是刚才的那个所以，为了知道之前到底是哪个用户访问的，各种网络软件提供商提出一个概念：会话机制 会话机制的流程如下

机制协商好之后，就是如何实现了，很简单，在服务器端，使用session来创建会话，在浏览器端，使用cookie来存储会话id，大概流程如下

这样，服务端就知道上一次访问的用户是谁了，同样，也就可以判断哪些用户登录了，服务端只需要把登录的状态保存在session就可以了

简单总结一下：

标准的http协议指的是不包括cookies, session，application的http协议，他们都不属于标准协议，但是各种网络应用提供商，为了清楚上一次的访问者，提出并实现了会话机制，各种编程语言、web容器等，都默认支持它，前端基于cookie，服务端基于session

但是随着业务越来越复杂，慢慢的出现了下面这种情况：

不仅用户嫌麻烦，老板也不答应啦老板说我要这样的：

所以，就引出了接下来咱们的主角：单点登录

多系统的单点登录

Single Sign On（简称SSO）要实现的效果：一次输入密码多个网站可以自动识别在线状态

单点登录关键点在于用户认证(存储信任验证信任)，场景：多个系统自动登

多平台登录关键点在于用户授权OAuth2.0，场景：三方登录，比如微信登录

相同根域下的单点登录，比如a.baidu.com、b.baidu.com 这种情况下的单点登录，实现比较简单，只需要设置cookie的存取是基于根域(baidu.com)就行，这种方式实现的单点登录有如下几个缺陷：

不同根域下的单点登录，比如a.com、b.com 显然，这种问题依赖cookie解决不了了，这个时候需要一个“中介”来参与一下：CAS(Central Authentication Service)认证中心服务，独立的SSO系统具体流程如下：

小疑问：SSO系统登录后，跳回原业务系统时，带了个参数令牌，业务系统还要拿令牌再次访问SSO进行验证，多余吗？为什么？解释放到最后

说完登录，基于CAS的注销流程如下：

总结一下基于CAS的会话特点：

1.局部会话存在，全局会话一定存在

2.全局会话存在，局部会话不一定存在

3.全局会话销毁，局部会话必须销毁

最后补充一个知识点：会话管理机制

1.基于server-session的管理方式

2.cookie-based的管理方式

3.token-based的管理方式

可以看到，token-based其实和cookie-based的方式基本一样，只不过不是通过cookie来实现，而是自己选择存储位置，自己主动把token放到header参数里面，现在基本都是这一种，不管是前端spa，还是原生app

基于token-based的管理方式也有现成的方案标准可用，这个标准就是JWT(json-web-token)，JWT本身并没有做任何技术实现，它只是定义了token-based的管理方式该如何实现，它规定了token的应该包含的标准内容以及token的生成过程和方法

最后回答一下文中留的一个疑问：答案肯定是不多余，试想一下，如果用户直接携带一个令牌给认证中心岂不是出问题了，所以，还是需要验证令牌有效性的