前端和后端采用接口访问时的调用验证机制（基于JWT的前后端验证）（思路探讨）
说明：基于前后端，尤其是使用Ajax请求的接口，现在市面上网页上调用的Ajax基本都是没有验证的，如果单独提取之后可以无线的刷数据。
继上一篇http://www.cnblogs.com/EasonJim/p/6178402.html文档所提到的Ajax请求的接口验证问题，现在基本上有了解决思路了，就是JWT标准，注意，这个是一个标准协议，和oAuth这种协议类似。
JWT主要实现的Token机制，为每一个需要调用的接口生成验证的Token，然后后端进行验证合法性。
JWT是一个标准，那么实现这个标准的语言就非常多，比如C，C++，Java等，具体的参考官方提供的文档即可。
生成原理：比如我们请求一个接口时，会使用JWT生成的Token，一同传递到后端进行验证合法性，对于生成Token可以是页面载入的时候写到Cookie，或者写到页面的固定位置。
可能遇到的问题和解决方案：
1、如果基于Java Web系统，前后端没有做分离时，基本页面输出使用了Java Web的模板引擎的，可以为输出的页面带上生成Token字符串，然后这些Ajax请求全部带上这个Token。
1.1、可能会出现这个Token暴露在页面，然后用工具提取到，然后进行请求；对于这个问题可以这样做，Token本身有过期机制，比如2个小时过期，这样一般能杜绝绝对部分的请求。
1.2、再加强一下，比如请求的接口上做一个验证，比如获取请求时判断上一个请求的头上Referer值，看下是否为当前域名下的。
1.2、比如生成Token时，带上请求的参数进行生成再输出，这样也就一个Token只能做一个参数的请求，也能杜绝掉一大部分的伪造请求。
1.3、对于生成Token，可以是单独的接口，但这样有点危险，可能会让人提取去用，但是如果判断只能当前域名下使用可能会有效。
1.4、也可以这样生成这个Token，比如我们要访问的B页面，那么先请求A页面再跳转到B页面，此时就会带上Token在Cookie上，然后再请求。不过同样也会被提取的风险。
1.5、学微信的做法，微信的前端JS做了Token的验证，比如页面上写好AppID，然后Token是服务端生成好放入到页面的，并且与域名进行绑定，如果域名变了，就无法使用这个Token请求。那么我们还是回到Referer的判断上进行判断，是否是本域名发出的请求。
2、如果是别的系统进行调用时，比如前后端分离的方案，需要使用到Ajax进行请求第三方接口的。
2.1、没办法，这个Token只能有后端生成好给你，然后你再使用它进行请求，并且第三方接口上也会判断Referer的来源域名。
2.2、还是使用上面的A和B页面进行跳转，然后获取Token，当然这个A页面可以是第三方去做，然后针对域名写Cookie。
3、综上，基本上是生成Token要过期时间，要判断请求的来源域名。、
4、针对Ajax是没有绝对安全的，只能做到比较安全；最明显的例子就是微信Web端，网上同样针对微信的Web API进行抓包分析，然后实现了请求的。既然加了Token机制只是为了再复杂多一步，使刷包的人做多一步难的操作。
参考：
http://m.blog.csdn.net/zwz568017880/article/details/61197587
