上篇文章說到接口安全的設計思路，如果沒有看到上篇部落格，建議看完再來看這個。
通過園友們的讨論，以及我自己查了些資料，然後對接口安全做一個相對完善的總結，承諾給大家寫個demo，今天一并放出。
對于安全也是相對的，下面我來根據安全級别分析
1.完全開放的接口
有沒有這樣的接口，誰都可以調用，誰都可以通路，不受時間空間限制，隻要能連上網際網路就能調用，毫無安全可言。
實話說，這樣的接口我們天天都在接觸，你查快遞，你查天氣預報，你查飛機，火車班次等，這些都是有公共的接口。
我把這稱之為裸奔時代。代碼如下：
View Code
2.接口參數加密（基礎加密）
你寫個接口，你隻想讓特定的調用方使用，你把這些調用的人叫到一個小屋子，給他們宣布說我這裡有個接口隻打算給你們用，我給你們每人一把鑰匙，你們用的時候拿着這把鑰匙即可。
這把鑰匙就是我上文說到的參數加密規則，有了這個規則就能調用。
這有安全問題啊，這裡面的某個成員如果哪個不小心丢了鑰匙或者被人竊取，掌握鑰匙的人是不是也可以來掉用接口了呢？而且他可以複制很多鑰匙給不明不白的人用。
相當于有人拿到了你的請求連結，如果業務沒有對連結唯一性做判斷（實際上業務邏輯通常不會把每次請求的加密簽名記錄下來，是以不會做唯一性判斷），就會被重複調用，有一定安全漏洞，怎麼破？先看這個場景的代碼，然後繼續往下看！
3.接口參數加密+接口時效性驗證（一般達到這個級别已經非常安全了）
繼上一步，你發現有不明不白的人調用你的接口，你很不爽，随即把真正需要調用接口的人又叫來，告訴他們每天給他們換一把鑰匙。和往常一樣，有個别夥伴的鑰匙被小偷偷走了，小偷煞費苦心，經過數天的踩點觀察，準備在一個月黑風高的夜晚動手。拿出鑰匙，搗鼓了半天也無法開啟你的神聖之門，因為小偷不知道你天天都在換新鑰匙。
小偷不服，經過一段時間琢磨，小偷發現了你們換鑰匙的規律。在一次獲得鑰匙之後，不加思索，當天就動手了，因為他知道他手裡的鑰匙在第二天你更換鑰匙後就失效了。
結果，小偷如願。怎麼破？先看這個場景的代碼，然後繼續往下看！
4.接口參數加密+時效性驗證+私鑰（達到這個級别安全性固若金湯）
繼上一步，你發現道高一尺魔高一丈，仍然有偷盜事情發生。咋辦呢？你打算下血本，給每個人配一把鑰匙的基礎上，再給每個人發個暗号，即使鑰匙被小偷弄去了，小偷沒有暗号，任然無法如願。即使小偷真正的如願，這樣也很容易定位是誰的暗号洩漏問題，找到問題根源，隻需要給目前這個人換下鑰匙就行了，不用大動幹戈。
但這個并不是萬無一失的，因為鑰匙和暗号畢竟還有可能被小偷搞到。代碼如下：
5.接口參數加密+時效性驗證+私鑰+Https（我把這個級别稱之為金鐘罩，世間最安全莫過于此）
繼上一步，我們給傳輸機制改為Https，這下小偷徹底懵逼了。那麼問題來了，Https咋玩兒呢？可以在本地搭個環境，參考此文：http://www.cnblogs.com/naniannayue/archive/2012/11/19/2776948.html
另：本文的接口是用的MVC WebAPI寫的，完全基于RESTful标準。如對此不是特别了解可以參考此文：http://www.cnblogs.com/landeanfen/p/5501490.html
完整demo下載下傳
注：demo不能直接運作，需要把兩個web項目配置到iis中，api代表接口提供方，他的主域需要配置到business的webconfig中，在浏覽器位址欄分别請求business中的各個調用接口方法來實作接口調用。
1、如果想驗證參數錯誤，需要在請求接口時打個斷點把接口url取出，篡改url參數，然後在浏覽器中模拟請求
2、如果想驗證接口逾時，需要在請求接口時打個斷點把接口url取出，然後等到了逾時時間，然後在浏覽器中模拟請求
3、如果想驗證私鑰錯誤，需要在請求接口時打個斷點把接口url取出，然後修改business的私鑰配置，然後在浏覽器中模拟請求
作者：簡簡人事
出處：http://www.cnblogs.com/codeon/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接。