用户认证
在互联网倒退初期，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的，在肯定水平上对于浏览器比拟敌对，然而对于很多挪动端利用其实并不是太敌对。
cookie认证
因为session的认证信息保留在服务端，数据量达到肯定水平对服务器有肯定的压力，即便是采纳第三方的存储（比方redis）能够缓解这种问题，然而服务器和第三方存储的IO操作所破费的工夫有的时候也是很大的。在这种状况下，有的零碎放弃了session的认证形式，而间接采纳的最间接的cookie认证形式。
和session认证不同，用户的认证信息齐全存储在cookie中，换句话说用户的认证信息存储在客户端（这也是为什么不举荐在cookie认证中寄存敏感信息）。cookie认证这种形式的劣势就在于服务端没有了session存储的压力，每次辨认用户都只须要解析cookie的内容即可（解析cookie其实也须要破费工夫），相比拟第三方存储session的形式，缩小了一次网络IO操作，在肯定水平上进步了申请的响应速度，而且因为服务端处于无状态的模式，所以能够很不便的横向扩大。
基于cookie的认证形式也有很多毛病：
- cookie是存储在客户端的，所以在肯定水平上减少了能够伪造的几率，安全性上稍强劲一点。
- 因为cookie在浏览中有跨域的拦截，所以在有跨域需要的时候，须要服务器做相应的配置。
- cookie是有长度限度的，所以不宜存储过长的信息。
- 用户的客户端可能会禁用cookie，这个时候能够依附url传值来解决这个问题。
- 服务端想要操作cookie认证信息的生效，比拟艰难，不像session认证那样不便。
其实我司当初老的零碎都是利用的cookie验证形式，只不过cookie信息的加密算法很好，而且再加上全站https的策略，在肯定水平上安全性还是能够的（如果让我重构一次认证零碎，我不会抉择cookie认证）。
写在最初
无论是基于session的还是基于cookie的认证形式，都须要客户端上传标识，都须要服务端下发这个标识，并且对这个标识进行加密。尽管加密，然而不法之人一旦拿到这个标识还是能够进行一系列非法操作，所以这个标识里边最好能加上起源IP和过期工夫这些属性，再配置上https，能够更加无效的爱护整个认证流程和数据。兴许还有更好的认证形式，敬请期待！！
更多精彩文章
- 分布式大并发系列
- 架构设计系列
- 趣学算法和数据结构系列
- 设计模式系列