登录&单点登录介绍

COOKIE & SESSION & TOKEN

主要用来跟踪会话，识别用户所用。cookie 是客户端，session 是服务端的。

因为 http 是无状态协议，每一次的访问都不知道之前的状态，只能通过参数的方式来判断识别等。 cookie 也是 http 协议的一个补充。

- 有效期
- 不可跨域名
- 编码（unicode 中文，base64 二进制编码）
- 属性（name，value，maxAge，domain，secure，path，comment，version）

Cookie 使用

• 直接用户名密码
• 用户名加密规则
• 密码加密

Session

• 服务器端记录客户端状态的机制，使用上比cookie简单，增加了服务器的压力。保存在服务器上，客户端只有sessionId
• 会话：客户端浏览器和服务器之间的一系列交互的动作成为一个session
• session 值的是服务器端为客户端所开辟的存储空间，保存的信息就是用于保持状态

Session 的生命周期

• 为了提高存取速度，服务器一般把 session 存在在内存里。防止内存溢出
• 只有访问JSP、servlet等程序，才会创建session，只访问html、image等静态资源并不会创建session。另外，可以通过request.getSession(true)强制生成session、
• session 生成之后，只要用户访问，就会更新session 最后访问时间。
• 有效期：maxInactiveInterval 属性。也可以通过web.xml 文件中修改。

对浏览器要求

• 虽然 session 是服务器，对客户端透明，但是正常运行还是需要客户端浏览器的支持。因为 session 需要使用 cookie 作为识别标志。HTTP 协议是无状态的，session 不能依据 HTTP 连接来判断是否是同一客户，因此服务器向客户端浏览器发送一个名为 JsessionId 的Cookie，他的值为该 Session 的id。session 依据该cookie来识别是否为同一用户。
• 如果浏览器不支持 cookie 那么就不可以使用这种方式了。

Url 地址重写

• url 地址重写是客户端不支持
• cookie 的解决方案。url 地址重写的原理就是将该用户 session 的id 信息写入到url 中。

Cookie 和 Session 的异同

• cookie 客户端，session 服务器
• cookie 不安全，因为存放在本地
• 为了减轻服务器压力，使用cookie，设置 session 过期时间
• 单个cookie 在客户端的限制是3k。

Token

由于session 是文本，请求来的时候，不知道用户名密码是否一致，需要频繁去查询数据库。而 session 是需要存储空间的。给服务器带来了很大的压力。

Token 是服务端生成的一个字符串，以作客户端请求的一个令牌。当客户端第一次访问时，服务端会根据传过来的唯一userId ，加密后生成一个token，然后通过 BASE64 编码一下之后将这个 token 返回给客户端。下次请求只需要携带 Token 即可。服务器收到请求之后，会用同样的算法和秘钥去校验 Token。

Token 登录流程

客户端使用用户名和密码登录
服务端收到请求，去验证用户名和密码
验证成功后，服务端会签发一个 token，再把 token 发送给客户端
客户端收到 Token 以后把它存储起来，比如放在 Cookie
客户端每次请求服务端，携带服务端签发的 token
服务端收到请求，然后验证客户端请求里携带的token，如果验证成功，就像客户端返回请求数据。

单点登录机制

单系统登录机制

• 1、http 无状态协议，每次请求之间不关联，没有上一次访问的信息。

• 2、会话机制

  会话机制：启用 cookie & session 分别对应 客户端 & 服务端
  访问Tomcat 服务器时，浏览器中可以看到一个名为 JSESSIONID 的cookie，这就是 tomcat 会话机制维护的 会话 id。

• 3、登录机制

  底层：会话机制

多系统登录

目前项目发展成为多系统的方式，web系统由单系统发展成多系统组成的应用集群，复杂性应该由系统内部承担，而不是用户，对用户而言，都是一个统一的系统，也就是说，用户访问web系统的所有系统or 模块，应该登录或注销一次就够了。

• 单系统登录的局限：cookie 共享的实现（cookie的不可跨域性，domain可以解决一定的限制，但是不灵活，也有限制）。
  • 域名统一
  • 各系统使用的技术（至少是web服务器）要相同，不然cookie的key值不同，无法维护会话。
  • cookie 并不安全

单点登录：Single sign on，多系统应用群中登录一个系统，便可以在其他所有系统中得到授权而无需登录，包含单点登录 单点注销两部分。

SSO

基于CAS（central authentication service）

• 独立认证中心，只有认证中心能接受用户的用户名和密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。

• 间接授权：通过登录令牌实现，sso认证中心通过之后，创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以创建局部会话，局部会话和单系统登录的机制相同。

• 局部会话 & 全局会话：用户通过登录建立和认证中心的会话，称为全局会话；用户得到登录令牌之后和子系统的会话，称为局部会话。全局会话建立了，不一定有局部会话；但有局部会话，一定存在全局会话。

• 注销：sso 认证中心一直监听全局会话的状态，一旦全局会话销毁，监听器将通知所有注册系统执行注销操作。

Sso 登录的动作流程

1、用户访问子系统，没有登录令牌，访问sso中心，传递子系统url
2、未登录，访问登录页
3、用户名密码，
4、验证通过，建立全局会话，发送令牌。跳转子系统
5、子系统验证令牌，sso 已登录，注册子系统，
6、系统与用户建立局部会话，返回受保护资源
7、用户访问子系统2，没有令牌，访问sso，传递url
8、验证已登录，发送令牌，跳转
9、子系统验证令牌，注册子系统。返回结果

Sso 注销动作流程

1、用户在子系统1注销
2、子系统访问 sso 注销全局会话请求
3、sso 验证令牌有效，销毁全局会话，取出注册系统
3、sso 发送通知，通知各子系统销毁 局部会话
5、子系统接受消息，销毁局部会话
6、sso 引导至登录页面

问题

• 1、注册系统 和 令牌发放 之间的关系？
  • 注册是 SSOserver 内部保存登录状态的过程。ST 是令牌
• 2、什么时候需要去 SSO 验证令牌？
  • 登录验证后，先发放令牌，然后浏览器通过令牌访问 子系统时，子系统拿令牌去SSO server 验证。验证成功，注册系统。
• 3、登录不会通知其他子系统，带着什么东西去SSO 验证？
  • 验证通过 TGC 验证，TGC 中有包含 cookie，可以找到对应注册的系统，如果 TGC 验证成功，即认为登录过，发放ST，重定向到验证ST链接。
• 4、token & cookie & ST & TGC 之间的关系
  • TGC 是 SSO 全局的登录凭证，如果有 TGC，即保证登录。对应全局会话。
  • ST 是服务凭证，可以通过 TGC 生成对应服务的 ST。对应局部会话。
  • cookie 是浏览器客户端保存状态信息的机制。不同的子系统有不同的 cookie （子系统各自命名 名称即是 token名），SSO server 也有相应的cookie（一般名称为 TGC，JSESSIONID）。
  • token 子系统 SSO client 各自生成，用于方便校验 是否登录。

实现

- SSO 认证中心：sso-server
- 子系统：sso-client 认证中心客户端
- SSO 和 client 之间通过 HttpClient 或 webService 或 RPC、restfulAPI 都可以

系统

- 查看shiro的实现
- https://www.cnblogs.com/ywlaker/p/6113927.html 实现

SSO 名词解释

- TGT ticket granting ticket SSO 为用户签发的登录票据
    拥有了TGT，就可以证明在 CAS 登陆过。TGT 封装了cookie 以及 cookie对应的用户信息。用户在 CAS 认证成功后，CAS生成 cookie (TGC)，传递给浏览器，同时 CAS 会生成 TGT 对象，放入自己的缓存。把 cookie 值当成 key。 当请求过来时，只需要验证是否有 TGT 即可。

- ST service ticket 服务票据
    用户访问service，发现没有ST，会去CAS请求ST，如果带有cookie，则查找TGT，使用此对象生成对应的ST返回给用户，用户凭借ST去访问service。

总结
1、单点登录的重点是全局会话的建立；
2、局部会话还是很重要；可以通过服务本身做session的保存，也可以使用全局的session服务来管理session；
3、单点登出的时候，中心认证系统首先销毁全局会话，然后回调各个子系统进行局部会话的销毁，来达到单点登出的目的；
4、token是为了简化信息的传递，其作用是和 sessionId 一样的概念。