网红：快速理解 session/token/cookie

阅读时间，15分钟，要求：不理解也要死背 ，OK ？

Cookie

Web Application一般以HTTP协议作为传输协议,但HTTP协议是无状态的.也就是说server-side与client-side一旦数据交换完毕后，两者之间的连接就会被关闭. client-side再次发送请求时,需要建立新的连接,这就意味着server-side和client-side两者之间无法通过HTTP的连接来实现会话跟踪.显然,这是不合理的,因为这样无法保证完成一次Web Application业务流程中所产生的若干次请求/响应操作的原子性,从而会导致业务逻辑混乱. cookie就是为了解决这一问题所引入的会话跟踪机制.

实现原理:由server-side为client-side发放一张通行证,并以此来认证client-side的身份(出于安全性的考虑,这张通行证一般是临时的).而这些通行证就是cookie,本质上cookie就是一小段文本信息,里面包含了有如session_id/login-status/token等认证相关数据.

session

基于session 的用户认证借助于请求体对象 req 中的 session 数据来完成.

实现原理: 当 client-side 请求 server-side 并通过身份认证后, server-side 就会生成并保存身份认证相关的 session 数据, 并将对应的 sesssion_id 写入 cookie 然后再响应到 client-side, client-side 会把 cookie 文件保存在本地. 此后, client-side 的所有请求都会附带该 session_id, 以确定 server-side 是否存在对应的 session 数据以及检验 session 数据中的 login-status. 如果存在且 login-status 为 True, 则证明 client-side 是被信任的, 无须再次认证身份. 否则, 需要重新进入身份认证流程.

缺点:

·server-side 保存 session 数据会增加运维和存储开销

·因为一个session_id 只能被保存有对应 session 数据的 server-side 完成认证, 所以在拥有多台 server-side 集群架构的场景中会降低其扩展性.

·如果原生App 不具备 cookie 功能模块, 就会加大其接入 session 认证后端的难度.

简而言之, session 有如用户信息档案表, 里面包含了用户的认证信息和登录状态等信息. 而 cookie 就是用户通行证.

Token

token(令牌) 由 uid+time+sign[+固定参数] 组成:

·uid: 用户唯一身份标识

·time: 当前时间的时间戳

·sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接

·固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库

·由其组成可以看出, token 的认证方式类似于临时的证书签名, 并且是一种 server-side 无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是 server-side 并不会保存身份认证相关的数据, token 只被保存在 client-side 中的 cookie 或 localstorage(数据库).

·实现原理: 当 client-side 发送请求 server-side 并完成身份认证后, server-side 会生成但不保存一个 token, 而是将 token 以 cookie 或其他形式响应给 client-side. 此后 client-side 发送请求时都会在 Request-Header 中附带 token, server-side 收到 token 后再分发给其他的 身份认证服务 负责处理认证相关的业务. E.G. Openstack 中的 Keystone 项目会为整个云平台提供身份认证服务.

·缺点:

·因为token 一般都是 hash/encrypt 的字符串, 所以会额外附加 加密/解密 的性能开销

·有些加密方式同样存在安全隐患