OAuth2、CAS、SSO单点登录详解

1.基础知识

1.SSO 单点登录（Single sign-on）是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

2.CAS 中央认证服务（Central Authentication Service）
CAS是一种独立开放指令协议，针对Web的企业多应用单点登录解决方案，并试图成为一个认证和授权需求的综合平台。
主要解决企业内部的一系列产品登录问题，安全信任度要比oauth2高

3.OAuth2 是一种访问授权的开放标准。主要解决不同的企业之间的登录，本质是授权(如论坛用QQ登录)，有以下4种授权方式

3.1授权码(authorization code)：这是最常用的一种方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌，项目中常用的就是这种
—这种模式算是正宗的oauth2的授权模式
—设计了auth code，通过这个code再获取token
—支持refresh token

3.2隐藏式(implicit)：允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”，一般应用于纯前端项目
—这种模式比授权码模式少了code环节，回调url直接携带token
—这种模式的使用场景是基于浏览器的应用
—这种模式基于安全性考虑，建议把token时效设置短一些
—不支持refresh token

3.3密码式(resource owner password credentials)：直接通过用户名和密码的方式申请令牌，这方式是最不安全的方式
—这种模式是最不推荐的，因为client可能存了用户密码
—这种模式主要用来做遗留项目升级为oauth2的适配方案
—当然如果client是自家的应用，也是可以
—支持refresh token

3.4凭证式(client credentials)：这种方式的令牌是针对第三方应用，而不是针对用户的，既某个第三方应用的所有用户共用一个令牌，一般用于后台api服务消费者设计
—这种模式直接根据client的id和密钥即可获取token，无需用户参与
—这种模式比较合适消费api的后端服务，比如拉取一些用户信息等
—不支持refresh token

4.session与cookie
会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份
两者区别
1.cookie数据存放在客户的浏览器上，session数据放在服务器上；
2.cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session；
3.session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用cookie；
4.单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的cookie不能超过3K；

5.session-cookie机制出现的根源
由于HTTP是一种无状态的协议，同一浏览器向服务端发送多次请求，服务器无法识别，哪些请求是同一个浏览器发出的，服务器单从网络连接上无从知道客户身份。怎么办呢？那就给客户端们颁发一个通行证，每人一个，无论谁访问都必须携带自己的通行证。这样服务器就能从通行证上确认客户身份了，这也是Cookie的工作原理

5.1.为了标识哪些请求是属于同一个人，需要在请求里加一个标识参数

方法1–直接在url里加一个标识参数(对前端开发有侵入性)，如: token

方法2–http请求时，自动携带浏览器的cookie（对前端开发无知觉），如：sessionid=XXXXXXX

5.2.浏览器标识在网络上的传输，是明文的，不怎么安全

安全措施：改https来保障

5.3.cookie的使用限制—依赖域名，具有不可跨域名性

1.顶级域名下cookie，会被二级以下的域名请求，自动携带
2. 二级域名的cookie，不能携带被其它域名下的请求携带
3.不可跨域名，域名www.google.com颁发的Cookie不会被提交到域名www.baidu.com去

5.4在服务器后台，通过解读标识信息（token或jsessionid），来对应会话是哪个session
一个tomcat，被100个用户登陆，tomcat里一定有100个session，存储格式map{sessionid，session对象}
，通过前端传递的sessionid，来对应取的session，可以使用request.getSession(boolean create)来获取Session

其他协议大概了解下
6.OpenID 是一种开放标准和分散的认证协议。

7.Kerberos 是一种计算机网络 认证协议。

8.SAML 安全断言标记语言(Security Assertion Markup Language) 是一种开放标准，用于在认证和授权数据之间交换身份验证和授权数据

9.LDAP 轻量级目录访问协议（Lightweight Directory Access Protocol ）

2.各种登录原理

2.1单一登录

现象：同一系统，同一用户在同一时间内只能有一个会话（即一个用户只有一个在使用的浏览器）
原理：
1、把登录成功的用户放入session和缓存，缓存中格式：key:userID,value:sessionId
2、用户访问资源时，用拦截器（或过滤器）拦截用户请求，先判断用户是否已登录（根据session判断），若用户未登录，则定向到登录 页面提示用户登录
3、若用户session已登录，根据用户userID取出缓存数据，判断当前浏览器的sessionId与缓存的是否一致，若一致，则继续访问
4、若sessionId不一致，则将当期的session数据清空，用户登出，提示用户被踢出

2.2 CAS（单点登录）

现象：多个系统只需登录一次，无需重复登录
原理：授权服务器，被授权客户端
1、授权服务器（一个）保存了全局的一份session，客户端（多个）各自保存自己的session
2、客户端登录时判断自己的session是否已登录，若未登录，则（告诉浏览器）重定向到授权服务器（参数带上自己的地址，用于回调）
3、授权服务器判断全局的session是否已登录，若未登录则定向到登录页面，提示用户登录，登录成功后，授权服务器重定向到客户端（参数带上ticket【一个凭证号】）,设置过期时间，可以存到redis里
4、客户端收到ticket后，请求服务器获取用户信息，从redis里查询到相应的session
5、授权服务器同意客户端授权后，服务端保存用户信息至全局session，客户端将用户信息保存至本地session

2.3 session共享方式，实现的单点登陆

1、多个应用共用同一个顶级域名，sessionid被设置在顶级域名的cookie里
2、后台session通过redis实现共享（重写httprequest、httpsession 或使用springsession框架），即每个tomcat都在请求开始时，到redis查询session;在请求返回时，将自身session对象存入redis
3、当请求到达服务器时，服务器直接解读cookie中的sessionid，然后通过sessionid到redis中查找到对应会话session对象
4、后台判断请求是否已登陆，主要校验session对象中，是否存在登陆用户信息
5、整个校验过程，通过filter过滤器来拦截切入
6、登陆成功时，后台需要给页面设置cookie
7、为了request.getsession时，自动能拿到redis中共享的session，我们需要重写request的getsession方法（使用HttpServletRequestWrapper包装原request），HttpServletRequestWrapper类是HttpServletRequest类的装饰类，通过重写装饰类中的对应方法就可以改变HttpServletRequest对象的状态

2.4 OAuth2（登录授权）

现象：第三方系统访问主系统资源，用户无需将在主系统的账号告知第三方，只需通过主系统的授权，第三方就可使用主系统的资源（如：APP需使用微信支付，微信支付会提示用户是否授权，用户授权后，APP就可使用微信支付功能了）
原理：主系统，授权系统（给主系统授权用的，也可以跟主系统是同一个系统），第三方系统
1、第三方系统需要使用主系统的资源，第三方重定向到授权系统
2、根据不同的授权方式，授权系统提示用户授权
3、用户授权后，授权系统返回一个授权凭证（accessToken）给第三方系统(accessToken是有有效期的)
4、第三方使用accessToken访问主系统资源(accessToken失效后，第三方需重新请求授权系统，以获取新的accessToken)