Http - Token篇
HTTP是无状态协议，它本身不能以状态来区分和管理请求和响应。
Cookie和Session的局限
但是只要稍微复杂点的业务,基本上都要走上"有状态"的模式上来,比如前面已经介绍过Cookie和Session,随着Web技术的发展,特别是移动的星期,他们的劣势也凸显出来.
Cookie的局限
- 基于浏览器,为确保Cookie不被恶意使用,同时不会占据太多的磁盘空间,通常有数量和长度的限制,一般每个domain最多允许50条(IE6或更低版本最多20条);每个Cookie长度一般限制在4K以内(新版本浏览器慢慢扩大为8K);
- 基于纯文本的键值对,记录复杂对象时需要扩展
- 安全性较弱
- 不可跨域,每个Cookie都会绑定单一的域名,无法在别的域名下使用
Session的局限
- 开销大: 需要保存每个客户端的Session信息
- 难以扩展集群: 单服务器是很嗨皮的,但是服务器集群要如何保证Session的同步呢?
- 2.1 Session Sticky: 就是每个Session粘连在特定的机器上,每次都由同一个服务器来处理,这跟集群的初衷就有些背离了,毕竟有一台机器挂了,粘连他的客户端都会出错.
- 2.2 Session 复制: 各个服务器之间复制同步Session,这个方案有很明显的同步问题,并且消耗也大
- 2.3 将Session集中在一个服务器上处理,其他服务器需要Session时都到这里来取;这时风险就集中到了这台服务器.
Token
Session方案是客户端持有Session Id,服务端持有Session内容,这决定了服务端必须要处理Session的保存、索引、同步等一系列问题
那有没有一种方案,让客户端持有会话信息,每次请求的时候都发给服务端,不就可以不用处理这些问题了吗?
(Cookie: 这是在说我?)
当然,顺便避开Cookie的局限,这就是Token方案.
Token的一般流程
┌─────────────┐ 1. userName + password ┌───────────────┐
│ │ ───────────────────────> │ │
│ │ 2. Token │ │
│ │ <─────────────────────── │ │
│ Client │ │ Server │
│ │ 3. Request + Token │ │
│ │ ───────────────────────> │ │
│ │ 4. Response │ │
│ │ <─────────────────────── │ │
└─────────────┘ └───────────────┘
Token的安全基础: 认证授权
认证授权是一个很系统的内容,这里作简单的介绍:
1. 认证(Identification)
通俗地讲就是验证当前用户的身份,证明你是你.
常见的认证有:
- 用户名+密码
- 手机号+验证码
- 邮箱+验证码
2. 授权(Authorization)
授权就是授予访问某些资源的权限,即你能干什么.
授权和权限联系紧密
比如对于同一个论坛页面,游客只能看、普通会员能看能回复、管理员能看能回复还能改能删除.
3. 凭证(Credentials)
实现认证和授权需要一种媒介,用来标记访问者的身份
凭证通常要包含以下信息:
- 用户信息
- 签名信息
- 时效信息
常见的凭证有:
- JWT令牌
- SSH登录密钥
- 一次性密码
4. 鉴权(Authentication)
鉴权是指对于一个声明者所声明的身份权利的真实性进行鉴别确认的过程.
通常要对凭证有效性和真实性进行甄别.
Token的优势
- 无状态: 凭证中包含用户信息,服务端只需要做解析而不用去查数据库,这不仅仅是用空间换时间.在我看来,这与Http本身无状态的特性无疑是更契合的
- 安全
- 可扩展
- 支持移动设备
- 支持跨程序调用
浙公网安备 33010602011771号