快速理解 session/token/cookie 认证方式
目录
- 目录
- cookie
- session
- token
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 的字符串, 所以会额外附加 加密/解密 的性能开销
- 有些加密方式同样存在安全隐患