正文

认证当前的操作用户是有很多种的方式的，比如可以利用Cookie、Session以及自定义的token的方式，来表示用户的登录状态。但是，这些技术，都会造成一些安全性的问题和用户登录状态的共享问题。无法判断是否是真的是这个用户请求操作。例如：假设我们使用的是token来操作数据接口，很有可能会出现CSRF的漏洞攻击。攻击者仅仅考虑你的token就可以完成和你一样的操作。那如何有效的保证用户是用户自己操作的呢？

产生这么多的问题主要的原因是我们的token管的太宽了，我们使用一个token做了所有的事情。在我们的项目里面会有不同的优先级的接口、也会有不同等级的接口。普通的接口可以直接使用token就完成了，但是比如：支付，或者更加高级的接口不能简单的用token来进行解决，此时我们需要二次的验证。例如可以输入密码等；但是不乏会有黑客会获取到你的密码，模拟你的转账业务，进行转账。这个时候如何解决？可以采用增加失效时间戳，以及签证信息，在有效的时间内，请求这个接口是有效的，不再这个时间内，请求这个接口是无效的。正常流程请求这个接口是有效的。直接请求这个接口是无效的。这样我们就可以在很大的程度上避免一些关键的接口存在CSRF的问题。

那如何设计我们的token呢？我们想在我们的token上增加一些必要的数据，可以供给前端以及后端的使用。解决的方案是可以采用JWT的方式进行解决。

JWT：Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

JWT包含了3个部分：第一部分我们称它为头部（header),第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)，第三部分是签证（signature)。JWT是服务端的生成下发给用户的。这样既可以传递信息，也可以作为用户的token进行操作。大大增加了token的功能。有兴趣的可以查询一下