单点登录
1.认证（Authentication）和授权（Authorization）的区别是什么？
2.什么是Cookie？Cookie的作用是什么？如何使用在服务端使用Cookis?
3.Cookie和Session有什么区别？如何使用Session进行身份验证？
4.如果没有Cookie的话Session还能用吗？
5.为什么Cookie无法防止CSRF攻击，而Token可以？
6.什么是Token?什么是JWT？如何基于Token进行身份验证？
7.什么是OAuth2.0?
8.什么是SSO？
单点登录实现原理（SSO）
简介
- 单点登录是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统的保护资源，若用户在某个应用系统中进行注销登录，所有的应用系统都不能再直接访问保护资源，像一些知名的大型网站，如：淘宝与天猫、新浪微博与新浪博客等都用到了这个技术。
原理
单点登录
有一个独立的认证中心，只有认证中心才能接受用户的用户名和密码等信息进行认证，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，当用户提供的用户名和密码通过认证中心认证后，认证中心会创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌即得到了授权，然后创建局部会话。
示例：
下面对上图进行解释：
- 当用户还没进行用户登录的时候
- 用户去访问系统1的保护资源 ，系统1检测到用户还没登录，跳转至SSO认证中心，SSO认证中心也发现用户没有登录，就跳转到用户至认证中心的登录页面
- 用户在登录页面提交用户相应信息后，认证中心会校验用户信息，如果用户信息正确的话认证中心就会创建与该用户的全局会话（全局会话过期的时候，用户就需要重新登录了。全局会话中存的信息可能有令牌，用户信息，及该在各个系统的一些情况），同时创建授权令牌，然后进行下一步，否则认证中心给出提示（用户信息有误），待用户再次点击登录的时候，再一次进行校验用户信息
- 认证中心带着令牌跳转到用户最初请求的地址（系统1），系统1拿到令牌后去SSO认证中心校验令牌是否有效，SSO认证中心校验令牌，若该令牌有效则进行下一步
- 注册系统1，然后系统1使用该令牌创建和用户的局部会话（若局部会话过期，跳转至SSO认证中心，SSO认证中心发现用户已经登录，然后执行第3步），返回受保护资源
- 用户已经通过认证中心的认证后
用户访问系统2的保护资源，系统2发现用户未登录，跳转至SSO认证中心，SSO认证中心发现用户已经登录，就会带着令牌跳转回系统2，系统2拿到令牌后去SSO认证中心校验令牌是否有效，SSO认证中心返回有效，注册系统2，系统2使用该令牌创建与用户的局部会话，返回受保护资源。 - 如果系统1的局部会话存在的话，当用户去访问系统1的保护资源时，就直接返回保护资源，不需要去认证中心验证了
- 当用户还没进行用户登录的时候
局部会话存在，全局会话一定存在；全局会话存在，局部会话不一定存在；全局会话销毁，局部会话必须销毁
如果在校验令牌过程中发现客户端令牌和服务器端令牌不一致或者令牌过期的话，则用户之前的登录就过期了，用户需要重新登录关于令牌可参考：基于跨域单点登录令牌的设计与实现
单点注销
- 在一个子系统中注销，全局会话也会被注销，所有子系统的会话都会被注销
- 示例：
用户向系统1发出注销请求，系统1根据用户与系统1建立的会话id从会话中拿到令牌，向SSO认证中心发起注销请求，认证中心校验令牌有效，会销毁全局会话，同时取出此令牌注册的系统地址，认证中心向所有注册系统发出注销请求，各系统收到注销请求后销毁局部会话，认证中心引导用户跳转值登录页面。
整体陈述
- 单点登录涉及SSO认证中心与多个子系统，子系统与SSO认证中心需要通信（交换令牌、校验令牌及发起注销请求等），子系统中包含SSO的客户端，SSO认证中心是服务端
- 认证中心与客户端通信可通过 httpClient、web service、rpc、restful api（url是其中一种） 等实现
- 客户端与服务器端的功能
- 客户端：
- 拦截子系统未登录用户请求，跳转至sso认证中心
- 接收并存储sso认证中心发送的令牌
- 与服务器端通信，校验令牌的有效性
- 建立局部会话
- 拦截用户注销请求，向sso认证中心发送注销请求
- 接收sso认证中心发出的注销请求，销毁局部会话
- 服务器端：
- 验证用户的登录信息
- 创建全局会话
- 创建授权令牌
- 与客户端通信发送令牌
- 校验客户端令牌有效性
- 系统注册
- 接收客户端注销请求，注销所有会话
- 客户端：
一、oauth2与单点登陆的区别
1、oauth2，不同的企业之间的登陆，应用之间的信任度较低
2、单点登陆，是同一企业的产品系列间的登陆，相互信任度较高
二、session-cookie机制
1、session-cookie机制出现的根源， http连接是无状态的连接
——– 同一浏览器向服务端发送多次请求，服务器无法识别，哪些请求是同一个浏览器发出的
2、为了标识哪些请求是属于同一个人 ———- 需要在请求里加一个标识参数
方法1———–直接在url里加一个标识参数(对前端开发有侵入性)，如: token
方法2———–http请求时，自动携带浏览器的cookie（对前端开发无知觉），如：jsessionid=dfdfdfdfdf
3、浏览器标识在网络上的传输，是明文的，不安全的
———–安全措施：改https来保障
4、cookie的使用限制—依赖域名
————– 顶级域名下cookie，会被二级以下的域名请求，自动携带
————– 二级域名的cookie，不能携带被其它域名下的请求携带
5、在服务器后台，通过解读标识信息（token或jsessionid），来对应会话是哪个session
————— 一个tomcat，被1000个用户登陆，tomcat里一定有1000个session ——-》存储格式map《sessionid，session对象》
————— 通过前端传递的jsessionid，来对应取的session —— 动作发生时机request.getsession
三、session共享方式，实现的单点登陆
1、多个应用共用同一个顶级域名，sessionid被种在顶级域名的cookie里
2、后台session通过redis实现共享，即每个tomcat都在请求开始时，到redis查询session;在请求返回时，将自身session对象存入redis
3、当请求到达服务器时，服务器直接解读cookie中的sessionid，然后通过sessionid到redis中查找到对应会话session对象
4、后台判断请求是否已登陆，主要校验session对象中，是否存在登陆用户信息
5、整个校验过程，通过filter过滤器来拦截切入，如下图：
6、登陆成功时，后台需要给页面种cookie方法如下：
response里，反映的种cookie效果如下：
7、为了request.getsession时，自动能拿到redis中共享的session，
我们需要重写request的getsession方法（使用HttpServletRequestWrapper包装原request）
四、cas单点登陆方案
1、对于完全不同域名的系统，cookie是无法跨域名共享的
2、cas方案，直接启用一个专业的用来登陆的域名（比如：cas.com）来供所有的系统登陆。
3、当业务系统（如b.com）被打开时，借助cast系统来登陆，过程如下：
cas登陆的全过程：
（1）、b.com打开时，发现自己未登陆 —-》 于是跳转到cas.com去登陆
（2）、cas.com登陆页面被打开，用户输入帐户/密码登陆成功
（3）、cas.com登陆成功，种cookie到cas.com域名下 ———–》把sessionid放入后台redis《ticket，sesssionid》—页面跳回b.com
（4）、b.com重新被打开，发现仍然是未登陆，但是有了一个ticket值
（5）、b.com用ticket值，到redis里查到sessionid，并做session同步 —— 》种cookie给自己，页面原地重跳
（6）、b.com打开自己页面，此时有了cookie，后台校验登陆状态，成功
（7）整个过程交互，列图如下：
4、cas.com的登陆页面被打开时,如果此时cas.com本来就是登陆状态的,则自动返回生成ticket给业务系统
整个单点登陆的关键部位，是利用cas.com的cookie保持cas.com是登陆状态,此后任何第三个系统跳入,都将自动完成登陆过程
5,本示例中,使用了redis来做cas的服务接口,请根据工作情况,自行替换为合适的服务接口(主要是根据sessionid来判断用户是否已登陆)
6,为提高安全性,ticket应该使用过即作废(本例中,会用有效期机制)
