使用Vue.js开发的前后端分离的项目如何做用户身份认证？

Question

是像传统项目一样用session，还是将用户名密码发送到一个登录接口之后返回一个access_token，然后将这个access_token和用户uid的关系存入数据库或者缓存，每次请求的时候通过客户端携带的这个access_token来进行身份验证？

能不能分析分析两种方法的优劣？

我个人的看法是：前者开发起来会比较简单，直接取session即可。后者这种方式可以实现原生APP和网页公用一套后端接口。

Answer 1

首先,先说结论,安全程度基本上都是一样的,cookie或者token被劫持了一样能伪造请求,所以需要结合实际场景判断那种方式更优

其次,要看你使用场景,是外包项目的话怎么简单怎么来,如果是自己练习或者公司项目,则要做对自己有挑战的,或者大家公认对公司项目高可用,易扩展的

最后,其实原理都差不多,都是要携带必要的信息作为权限认证

使用session相当于在浏览器中存了cookie,每次发请求的时候检查cookie就行,负载均衡上面在入口分发请求的设备上面做鉴权就可以了,如果单台服务器就更简单了

token更偏向于客户端的用法,不同的是需要你把token换成uid,而session则是大部分编程语言自己来处理的

最后说说我司的做法,我司APP使用的是token,因为APP是编译的生成,对token的加密方法保护得很好

如果是网页则是先登录授权服务器,换取一个token,然后再带着这个token登录各个不同的服务项目,由各个服务自己使用该token想授权服务器验证,如果通过验证,在给各个服务独有的session或者token

Answer 2

谢邀。上午在忙，没来得及回复，不好意思

既然你做的是前后端分离，那想必vue+node作为前端项目，后端数据相关的业务操作是其他程序负责了。
所以node端主要是维持cookie session，保持用于登录状态，负责接口转发。那么后端业务域名可以做局域网的，不对外公开(如果不提供API给第三方)，那么安全性已经上升很多了，不知道你们的场景是不是这样。

ok，那么你说的两种处理方案，其实也没有什么劣势优势。因为只有将session中的uid保证不会被恶意修改就好了，使用session也挺好，持久化到mongodb或者redis，配合分布式负载均衡效果很棒的。
关于你说的两种方案：

1. session。 一般网站都会在请求的时候通过session判断是否登录什么的，这个cookie被模拟或者劫持，服务器就懵逼了，人家可以随意发请求修改数据了，任何用户的数据。所以如果使用session，一定要注意cookie的操作安全性，防止客户端可以修改cookie内容。至于优势：就是简单呗

2. token。 对于后端数据接口还是有必要的，这个安全判断交给后端也是合情合理，生产机制什么的完全让他们去做，你只需要登录获取token保存好就可以了，也没有多麻烦。安全上要比session高点。

但其实当别人把cookie模拟，token破解服务器一样懵逼。。。

大概说一下，我认为现在的用户安全认证无非就是为了两点：

1. 识别是哪个用户，确认请求对号入座，不能因为a用户改了客户端uid就修改了b用户的数据(简单举例)。

2. 防止恶意并发请求的攻击。

不过建议使用session + token，防止客户端攻击就好了。数据安全比什么都重要。
然后node端与后端都需要对恶意多请求做防御，如果觉得有必要的话……

其实真要有人想搞你们，用什么都防不住。只有防住那些闲着蛋疼无聊手贱的人就好了……

Answer 3

session，在处理分布式，负载均衡上比较有劣势。
后者可以更好地做集成。也比较好跨设备处理。

Answer 4

之前做的SPA的项目，使用的是TOKEN认证的方式，个人认为TOKEN相对较安全，如果你的项目会暴露出API给第三方，建议使用TOKEN，否则，我觉得两者都可以使用

Answer 5

你的这个问题解决方式有很多，但是具体还是看技术这块的架构。说一说我司的做法吧，我们每一个项目会有一个key，这个key是一段没有规律的字符串，然后不同的环境下key是不同的（例如开发环境，测试，生产等）。然后cookie,和session(我们有一套封装好的请求校验这块的js库)，然后用这个库去封装好的方法去请求服务端，服务端还会进行校验，若果是这些东西不满足，那么会禁止它进行请求。（我们后台有一个统一的网关，我们并不是直接请求服务端，而是向这个网关发起请求，网关会处理什么负载均衡已经安全的处理）。也不知道是否能对你有帮助，提供给你参考一下吧！

Answer 6

如果还有app端的话，感觉用token方便点，app和h5一套接口