一、序言
对从事Web开发的或者有过Web开发经验的朋友来说,身份验证一定是一个避不开的话题。即使是再小的系统,也少不了登录这道程序。不管是前端还是后端,总要和会话打交道,那么,就从会话开始,聊聊常用的验证方式:Cookie、Session、Token。
在计算机术语中,会话是指一个终端用户与交互系统进行通讯的过程,TCP的三次握手就创建了一个会话,TCP关闭连接就是关闭会话。理论上,一个用户的所有请求操作都应该属于同一个会话。但是,Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕,客户端与服务器端的连接就会关闭,再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。所以要跟踪用户会话,就需要引入会话跟踪机制。
二、Cookie
Cookie是一段用户文本信息,它存放在用户请求头信息中:
客户端第一次访问服务器的时候,服务器如果验证通过,就可以使用response向客户端返回一个Cookie,客户端将Cookie保存,下次向服务器进行请求时,请求头中就会携带服务器颁发的Cookie信息。可以理解为:由于http的无状态特性,服务器端需要借助一种认证方式来识别客户端身份,通过Cookie相当于给客户端颁发一个通行证,当客户端携带通行证进行访问时,服务器就可以通过通行证中的信息来识别客户端身份。
Cookie存放在客户端,具有不可跨域名性。前端与后端都可以进行Cookie的设置与修改,当设置Cookie时未设置对应的过期时间或过期时间设置为非正数,则该Cookie会被认为是临时性Cookie,不会被写入Cookie文件中,在用户关闭浏览器后,Cookie即自动消失;相反,如果显式设置Cookie过期时间,则Cookie会被写入Cookie文件,如果用户关闭了浏览器,但只要Cookie仍在过期时间之内,则Cookie依然生效。如果设置过期时间如下,则该Cookie永远生效:
cookie.setMaxAge(Integer.MAX_VALUE); // 设置生命周期为MAX_VALUE
Cookie不存在显式的修改及删除操作,如果要修改某个Cookie,只需要新建一个同名的Cookie,添加到response中覆盖原来的Cookie。如果要删除某个Cookie,只需要新建一个同名的Cookie,并将maxAge设置为0,并添加到response中覆盖原来的Cookie。注意是0而不是负数。(修改、删除Cookie时,新建的Cookie除value、maxAge之外的所有属性,例如name、path、domain等,都要与原Cookie完全一样。否则,浏览器将视为两个不同的Cookie不予覆盖,导致修改、删除失败。)
由于其可以被客户端获取及修改,因此,为保障网络安全,一般建议对Cookie进行加密。
三、Session
Session是服务器端使用的一种记录客户端状态的机制,使用上比Cookie简单一些,相应的也增加了服务器的存储压力。
Session是另一种记录客户状态的机制,不同的是Cookie保存在客户端浏览器中,而Session保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话,那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案,客户来访的时候只需要查询客户档案表就可以了。
Session对象是在客户端第一次请求服务器的时候创建的。Session也是一种key-value的属性对 ,为了获得更高的存取速度,服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂,当大量客户访问服务器时可能会导致内存溢出。因此,Session里的信息应该尽量精简。
Session生成后,只要用户继续访问,服务器就会更新Session的最后访问时间,并维护该Session。为防止内存溢出,服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器,Session就自动失效了。
虽然Session保存在服务器端,但Session的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的,Session不能依据HTTP连接来判断是否为同一客户,因此服务器向客户端浏览器发送一个名为JSESSIONID的Cookie,它的值为该Session的id(也就是HttpSession.getId()的返回值)。Session依据该Cookie来识别是否为同一用户。
四、Token
当讨论基于token的身份验证时,一般都是说的JSON Web Tokens(JWT)。虽然有着很多不同的方式实现token,但是JWT已经成为了事实上的标准,所以后面会将JWT和token混用。
基于token的验证是无状态的。服务器不记录哪些用户已登陆或者已经发布了哪些JWT。对服务器的每个请求都需要带上验证请求的token。该标记既可以加在header中,可以在POST请求的主体中发送,也可以作为查询参数发送。
Token的验证流程如下:
- 用户输入登陆凭据;
- 服务器验证凭据是否正确,然后返回一个经过签名的token;
- 客户端负责存储token,可以存在local storage,或者cookie中;
- 对服务器的请求带上这个token;
- 服务器对JWT进行解码,如果token有效,则处理该请求;
- 一旦用户登出,客户端销毁token。
从以上请求验证流程对比不难看出,Token不存在跨域问题,相比于Cookie的有状态性,基于token的验证是无状态的,这也许是它相对cookie来说最大的优点。后端服务不需要记录token。每个令牌都是独立的,包括检查其有效性所需的所有数据,并通过声明传达用户信息。
JWT具有两个特点:
- 紧凑。由于其较小的尺寸,JWT可以通过URL,POST参数或者HTTP头发送。较小的尺寸会带来传输速度的优势;
- 自包含:token中包含了用户的所有必须信息,避免了多次查询数据库的需要。
当然,JWT同样存在自己的缺点:其 最大的缺点就是它的大小,最小的它都比 cookie 要大,如果 token 中包含很多声明,那问题就会变得比较严重,毕竟向服务器发送的每个请求都要有这个 token。(意思应该是太大了会导致请求缓慢)
五、小结
对于简单的小型应用而言,使用Session配合Cookie进行简单的用户身份验证就足够了。但在大型应用中,Session的大量存储会使得服务器不堪重负。事实上,现在的互联网公司普遍使用Token进行身份验证。当然,以上技术均有其优缺点,基于不同场景、不同需求,选择合适的方式即可。