用户认证

基于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就消失。对于Session来说，除非程序通知服务器去删除一个Session，否则服务器会一直保留这个Session直到它过期，并不是关闭浏览器Session就消失。由于大部分cookie/session认证机制都使用cookie来保存session id，而关闭浏览器后消失的是session id，再次打开浏览器去请求服务器时，没有了session id就找不到原来的Session，因此需要重新登录。或者，可以将session id保存在本地，使得再次打开浏览器访问时仍然能够保持登录状态。

弊端

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

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

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

　　4、Session需要基于cookie实现，当浏览器禁止cookie或不支持cookie时，一般需要把session id跟在URL参数后面重写URL。

　　5、移动端对cookie的支持不是很友好，一般用的是Token。

基于Token的认证方案

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

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

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

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

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

今天的文章用户认证分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。