API接口，類似 /refund/order_id=123&mch_id=123 ，這個請求我以商戶mch_id=123的身份給訂單號為order_id=123退款，如果服務器不辯別請求發起者的身份直接做相應的操作，那是及其危險的。
壹般的，在PC端，我們是通過加密的cookie來做會員的辨識和維持會話的；但是cookie是屬於瀏覽器的本地存儲功能。APP端不能用，所以我們得通過token參數來辨識會員；而這個token該如何處理呢？
延伸開來，接口的安全性主要圍繞Token、Timestamp和Sign三個機制展開設計，保證接口的數據不會被篡改和重復調用。
壹般來說，在前端對數據做加密或者前面，是不現實的。前後端使用HTTP協議進行交互的時候，由於HTTP報文為明文，所以通常情況下對於比較敏感的信息可以通過在前端加密，然後在後端解密實現"混淆"的效果，避免在傳輸過程中敏感信息的泄露（如，密碼，證件信息等）。不過前端加密只能保證傳輸過程中信息是‘混淆’過的，對於高手來說，打個debugger，照樣可以獲取到數據，並不安全，所謂的前端加密只是稍微增加了攻擊者的成本，並不能保證真正的安全。即使妳說在前端做了RSA公鑰加密，也很有可能被高手獲取到公鑰，並使用該公鑰加密數據後發給服務端，所以務必認為前端的數據是不可靠的，服務端要加以辯別。敏感信息建議上/wiki/doc/api/jsapi.php?chapter=4_3
第1點中，其簽名算法最重要的壹步，是在最後拼接了商戶私密的API密鑰，然後通過md5生成簽名，這時即使金額是明文也是安全的，如果有人獲取並修改了金額，但是簽名字段他是無法偽造的，因為他無法知道商戶的API密鑰。當然，除了微信支付的拼接API生成簽名的方法，我們也可以通過java自帶的security包進行私鑰簽名。其中nonce隨機字符串，微信支付應該做了校驗，可以防止重放攻擊，保證壹次請求有效，如果nonce在微信支付那邊已經存在，說明該請求已執行過，拒絕執行該請求。
阮壹峰老師的博客-RSA算法原理： /blog/2013/07/rsa_algorithm_part_two.html
維基百科： https://zh.wikipedia.org/wiki/RSA%E5%8A%A0%E5%AF%86%E6%BC%94%E7%AE%97%E6%B3%95