http协议本身是无状态的,但是在实际的web开发中常有一些操作需要有状态.比如想要访问一些私人访问权限的文章,或者这种操作需要明确当前用户身份.

显然,最简单的方案就是每次都发送账户和密码,但是这样重复操作用用户并不友好,对服务器页增添了额外的压力.为了解决无状态带来的鉴权问题,一般有以下几种解决方案:cookie、session、token.至于标题中提及的outh2、jwt本质上也是token方案.

cookie

Cookie是储存在客户端的一串字符,一般说来大小不超过4kb.比如我们常见的记住密码功能,或者一些基于之前输入的提醒和默认配置,就是通过cookie来实现的,cookie简单说来就是一种本地存储方法.但是这里存储的信息常用来进行鉴权操作.cookie只能保存文本信息,浏览器可以禁止cookie.cookie的期限可以被自由设定,可以是仅仅一次浏览起效,也可以长达一年.如果是短期的,那么这些信息会被存储在内存中,如果是长期则会存储在硬盘上.cookie的起效范围是路径下的所有子路径.不允许其他来源的访问.

单纯的采用cookie来认证身份会带来一个比较麻烦的问题,就是伪造比较容易.因为这样处理,cookie中必然要带有身份信息,但是服务器也要解析这个身份信息,所以必然要在原理上支持双向的编码和解码,那么这个信息很容易被破解和进一步伪造.想一想,如果想要解决这个问题,我们常用的方案应该是加一个secret,而这个secret应该是放在服务器上的,服务器返回这样一个带有secret编码的字符串,而在服务器端再带上这个secret反向解密,如此一来,问题不就解决了吗?确实如此,但是这不代表cookie就安全,因为这已经不叫cookie了,而是我们要讲的第二个对象:session.

session

通过上面说的东西,我们已经能够获得身份信息,额外的,我们还可以把更复杂形式的信息都存储进来,因为这里没有cookie的纯文本限制.但是刚才说的带有secret编码的字符串也就是sessionid,依然要存储在客户端.是不是意味着session必定要依赖cookie呢?不是!想一想,我们实际上需要的是在每一次请求(至少是需要判定身份状态的请求中),都带上这个字符串,我们有以下这几种解决方案:

  1. cookie
  2. 表单隐藏字段:在form中放置一个隐藏的域
  3. url重写:在url后边加上session的query段

Session也可以设定有效时间.其实际的存储可以在内存、缓存、文件中.通过类似//可能具体实现不同.//hash表的数据结构存储.cookie是一个存在的实体,session是一种机制.

token

对token的理解还不够,可能多有纰漏之处,待之后再进行修改.

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

  1. 客户端使用用户名跟密码请求登录
  2. 服务端收到请求，去验证用户名与密码
  3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
    客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
  4. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
  5. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

可以看出来,这里的token与sessionid有些类似,其区别:

  1. sessionid是带着之前的状态的,在服务器端可以getSession(sessionid)
  2. token是在登录验证之后发放的一个包含着用户基本信息的较长的字符串,用处是验证身份以及简化后续获取信息的难度.
  3. token机制更灵活,可以实现跨域
jwt

Jwt简单说来是一种token的具体实现规范!

Jwt标准的token有三个部分,中间用点分隔开，并且都会使用 Base64 编码:

  1. header。header 部分主要是两部分内容，一个是 Token 的类型，另一个是使用的算法
  2. Payload。里面是 Token 的具体内容，这些内容里面有一些是标准字段，你也可以添加其它需要的内容
  3. Signature。编码以上两个部分并且加入一个secret使用信息摘要算法得出一个字符串
oauth2

简单来说,oauth是用来向第三方平台提供可以细致的权限管理的一种方案.
如何直接向第三方提供账号和密码,可能存在的问题有:

  1. 不安全
  2. 无法更细致的限制授权范围和有效期
  3. 只有修改密码才能收回权限
  4. 一个第三方程序被破解将会导致用户密码泄漏

OAuth的基本思路如下:

OAuth在”客户端”与”服务提供商”之间，设置了一个授权层（authorization layer）。”客户端”不能直接登录”服务提供商”，只能登录授权层，以此将用户与客户端区分开来。”客户端”登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。”客户端”登录授权层以后，”服务提供商”根据令牌的权限范围和有效期，向”客户端”开放用户储存的资料。

原文来自：

本文地址：//gulass.cn/cookie-session-token-oauth2.html

编辑：倪家兴，审核员：逄增宝

本文原创地址：//gulass.cn/cookie-session-token-oauth2.html编辑：倪家兴，审核员：暂无