用户认证

基于cookie/session的认证方案

　　我们可能会认为仅使用cookie就能实现服务器标识用户的功能，但这会有很多弊端。首先，cookie中的数据能够在客户端被修改，安全性较低；其次，如果cookie的数据字段太多也影响传输效率。因此，Session的出现就是为了解决这些问题。相比于客户端，服务器的安全性相对较高，Session可以将原本需要发送给客户端的cookie保存在服务器，然后发送一个session id给客户端，与此Session关联起来。另外，单个cookie保存的数据不能超过4kb，而Session可存储的数据要大得多，并且对数据类型没有要求。

　　用户在首次请求服务器时，服务器会根据用户提交的相关信息，创建对应的Session，并将此Session的唯一标识 session id放置在cookie中返回给客户端。客户端收到cookie后，将它保存在本地。当下一次请求同一网站时，浏览器会自动判断该域名下是否存在cookie，若存在则将cookie发送给服务器。服务器会从cookie中获取到session id，根据session id查询对应的Session信息，如果找到则说明该用户已经登录过，可以执行后续操作。这样，当用户在应用程序的Web页面之间发生跳转时，无需重新登录。因为Session对象会在整个用户会话中存续，直到客户端关闭会话或者Session超时失效。

　　这种方案有其弊端：

　　1、每个用户发起认证请求时，服务器都需要去创建一个Session记录来存储信息，随着请求的用户越来越多，服务器开销也会越来越大；

　　2、使用负载均衡时有多台服务器来共同支撑用户请求，如果用户在服务器A登录了，第二次请求时由于负载均衡跑到了服务器B，就会出现登录失效的问题，因为Session仅存在服务器A中；

　　3、受cookie自身的影响，会有同源策略的限制，以及容易遭受CSRF（跨站请求伪造）攻击；

基于Token的认证方案

　　基于Token的用户认证是一种服务端无状态的认证方式，服务器无需存放Token数据，本质上是以解析Token的计算时间换取Session的存储空间。当用户首次登录时，服务器对用户提交的用户名和密码进行验证，验证成功后，服务器会签发一个token，并将其发送给客户端。客户端收到token后将其存储起来，当下一次请求同一网站时，发送携带该token的请求。服务器收到请求后，验证这个token，验证成功则返回请求的资源。

　　相比于使用cookie/session进行认证，token有如下优点：

　　1、token完全由应用管理，可以避开同源策略；

　　2、请求中发送token而不使用cookie可以有效防止CSRF；

　　3、有效解决前面分布式Session的问题