說明：基於前后端，尤其是使用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