程序员过关斩将--互联网人必备知识cookie和session认证

菜菜，上次你说的cookie和session的文章，我觉得不太具体

那你想怎么样具体呢？

我自己从网上查了一下，很多关于cookie和session认证的，能不能给我讲讲

用户认证呀，可以呀

这样我下次再去面试，有可能会遇到这样的问题

原来你是想为面试做准备呀，看来公司收不住你的心了

用户认证

在互联网发展初期，Web基本上只是内容的浏览而已，服务器不需要记住每个浏览请求的状态，换句话说，服务器不需要有任何的状态信息，每次客户端的请求都是新的请求，这也是http无状态一个很明显的表现。随着互联网大潮的到来，尤其是像在线购物等这种和用户关系密切的系统的大量兴起，系统需要辨识出用户，以便进行各种业务操作，这种需求给Http无状态这种特性一个强烈的冲击，所以最终的解决方案就是客户端请求的时候携带着一种标识，这种标识每个用户不同，这样服务端就可以根据这个标识区分出不同的客户端用户了，这也就诞生了用户认证这个概念。

由于http协议是无状态的，所以基于http协议进行的认证，都需要依赖客户端上传的某种标识。

所谓身份认证，就是判断一个用户是否为合法用户的处理过程。

以上是百科针对于用户认证的泛型定义，和认证相关的授权这里要顺便提一下，认证和授权是两个不同的概念，更是两个不同的阶段，绝大多数带有认证和授权的系统，在用户操作流程上都是先进行认证，之后根据认证的结果再进行授权操作，有的初学者容易混淆二者的概念。举一个很简答的栗子：一个OA系统，在用户登录成功之后，一般左侧都会根据当前用户的不同角色或者权限出现不同操作的菜单树，其中用户登录这个过程就是认证的过程，而左侧的菜单树就是对当前用户的授权的一个具体表现形式（当然有的系统可能不这样做，但不代表没有授权的流程）。

认证是用来证明一个用户身份的操作流程，授权是用来给当前用户赋予权限的操作流程

session认证

通过上一篇文章，相信大家已经明白了session和cookie的关系，如果你还没看过，我推荐还是看一下吧。

Session：在计算机中，尤其是在网络应用中，称为“会话控制”。Session对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的Web页之间跳转时，存储在Session对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web页时，如果该用户还没有会话，则Web服务器将自动创建一个Session对象。当会话过期或被放弃后，服务器将终止该会话。

基于session的认证方式，最主要的一个特点就是：服务端存储着用户信息，客户端是通过携带一个sessionid的cookie来做session的标识。很多初期项目都喜欢采用session的认证方式，这种方式对于快速开发上线项目极为有利。每个客户端只需要保存一个cookie，但是服务端却需要保存成千上万的用户session信息，这无疑对服务端造成了很大的压力，尤其是当做了负载均衡之后，session的命中问题更为可怕。举个栗子：用户A登录系统成功，服务器A下发sessionid，session信息存储在服务器A上，如果当下次请求到服务器B上的时候，由于服务器B上没有session信息，所以就造成了未命中的现象，这也是session认证解决方案实施过程面临的一个问题。有问题就有解决方案，其中一个便是session复制，服务端的每个服务器都存储每个session的一个副本，这样请求无论到达哪个服务器，都可以成功取到session信息，但是这样无疑增大了服务的存储压力，而且session在服务器之间的复制延迟，session信息的更新同步、过期同步等操作都令人头疼。所以这种方案在一定程度上其实并不推荐。

目前业界关于session存储的方案一般都倾向于集中式存储，像利用第三方的redis，Memcached把session信息都存储在同一个地方，所有的服务器都访问这个地方的数据。这样就避免了session复制，同步等问题。但是引入了第三方，就意味着增加了一个第三方挂掉的可能性，所以现在都基本采用第三方集群的方案来尽量减小这种可能性，把高可用性做到极致。另外说一点，由于大多数session机制是基于cookie的，在一定程度上对于浏览器比较友好，但是对于很多移动端应用其实并不是太友好。

由于session的认证信息保存在服务端，数据量到达一定程度对服务器有一定的压力，即使是采用第三方的存储（比如redis）可以缓解这种问题，但是服务器和第三方存储的IO操作所花费的时间有的时候也是很大的。在这种情况下，有的系统放弃了session的认证方式，而直接采用的最直接的cookie认证方式。

和session认证不同，用户的认证信息完全存储在cookie中，换句话说用户的认证信息存储在客户端（这也是为什么不推荐在cookie认证中存放敏感信息）。cookie认证这种方式的优势就在于服务端没有了session存储的压力，每次识别用户都只需要解析cookie的内容即可（解析cookie其实也需要花费时间），相比较第三方存储session的方式，减少了一次网络IO操作，在一定程度上提高了请求的响应速度，而且由于服务端处于无状态的形式，所以可以很方便的横向扩展。

基于cookie的认证方式也有很多缺点：

1. cookie是存储在客户端的，所以在一定程度上增加了可以伪造的几率，安全性上稍微弱一点。

2. 由于cookie在浏览中有跨域的阻拦，所以在有跨域需求的时候，需要服务器做相应的配置。

3. cookie是有长度限制的，所以不宜存储过长的信息。

4. 用户的客户端可能会禁用cookie，这个时候可以依靠url传值来解决这个问题。

5. 服务端想要操作cookie认证信息的失效，比较困难，不像session认证那样方便。

其实我司现在老的系统都是利用的cookie验证方式，只不过cookie信息的加密算法很好，而且再加上全站https的策略，在一定程度上安全性还是可以的（如果让我重构一次认证系统，我不会选择cookie认证）。

写在最后

无论是基于session的还是基于cookie的认证方式，都需要客户端上传标识，都需要服务端下发这个标识，并且对这个标识进行加密。虽然加密，但是不法之人一旦拿到这个标识还是可以进行一系列非法操作，所以这个标识里边最好能加上来源IP和过期时间这些属性，再配置上https，可以更加有效的保护整个认证流程和数据。也许还有更好的认证方式，敬请期待！！