在web開發的過程中，當對外提供的介面能夠被隨意呼叫時，可能造成非法使用者能夠對我們的伺服器進行惡意攻擊，導致伺服器不能有效處理正常的業務請求，因此需要考慮對這些暴露出去的http介面做防刷限制。
今天主要講一下我們的專案中用到的一種防刷機制——給對外介面加驗證身份的簽名（即驗籤）。
具體到業務中，當呼叫者b請求呼叫服務者a的介面時，服務者a需要驗證呼叫者b的身份，並通過簽名來驗證呼叫者的身份，整個流程大致如下：
首先服務者a為自己暴露的介面生成乙個金鑰key，並儲存在資料庫中，而且a提供生成簽名的加密演算法（比如hmacsha1演算法）
然後呼叫者b在呼叫a的介面時，將原有的引數資料連同這個簽名摘要一起傳遞給a。
服務者a接收到b的呼叫請求時，首先要驗證b傳過來的簽名是否合法，若驗證通過則繼續後續的處理；否則將返回乙個錯誤，中斷處理流程。
服務者a驗證簽名的方法大致為：首先採用相同的加密演算法和金鑰key對b傳來的引數資料進行加密，生成乙個新的簽名摘要newsignature，然後比較生成的newsignature和signature是否相同，若相同則驗證通過；否則驗證不通過。
服務者a把一套規則（金鑰和加密演算法）告訴呼叫者b（而且只告訴b，第三方無法得知），當b要呼叫a的介面時，b可以使用這套規則對自己要傳遞的資料info進行加密得到乙個簽名，然後把info和簽名一起傳送給服務者a，a接收到b傳過來的資料後，使用相同的規則對接收的info進行加密，得到乙個新的簽名，若這個新簽名和b傳過來的簽名相同，則說明生成這兩個簽名所使用的info、加密演算法和金鑰都是相同的，info沒有被篡改過，b的身份是真實的；若生成的新簽名和b傳過來的簽名不相同，則說明生成這兩個簽名所使用的info、加密演算法和金鑰不是完全相同的（注意金鑰和加密演算法封裝隱蔽在服務者a的內部，不會洩露出去），有可能info被篡改了，也有可能info沒被篡改，但是使用的加密演算法或金鑰和服務者a約定的不同，那麼這個呼叫者可能就不是真實的b，真實的b肯定使用服務者a約定的演算法和金鑰去生成info簽名，得到的簽名和服務者a計算出的一定是相同的（基於下方所述的sha1的特性）。
所以通過驗證簽名，可以驗證兩個事情：1.呼叫者傳送的資訊在傳輸過程中是否被篡改過 或 2.呼叫者身份是否是合法的。
不管是傳送的資訊被篡改，還是介面被非法呼叫，服務者a都會視為認證錯誤，中斷處理流程。
hmac是指基於雜湊的資訊認證編碼（hash-based message authentication code）
sha1是一種安全雜湊演算法，對於限定長度的資訊，通過sha1可以生成乙個固定長度的資訊摘要，可以使用資訊摘要驗證資訊的完整性。sha1具有兩個特性：1.不可逆，無法根據資訊摘要獲取原資訊。2.兩個不同的資訊不會產生同樣的資訊摘要。
hmac-sha1則指使用sha1雜湊演算法和乙個私鑰加密生成hmac的一種mac（資訊認證碼）演算法。
或者說更生動、形象一些，這太重要了，生動形象讓人印象深刻。
a對b說，要使用的我的服務，必須要按照我的規則來調。
b：什麼規則？
a：每次呼叫我的服務，都要用我提供的金鑰和加密演算法來加密你要給我發的資訊，生成乙個簽名，然後將你的資訊連同這個簽名一塊傳送給我。
b：why？
a：因為我要驗證你的身份啊，我只給你乙個人提供這個服務，其他人都沒門。只要我用相同的金鑰和加密演算法對你的資訊進行加密得到的簽名，和你發給我的簽名是一樣的，那你肯定就是你了。
b：pardon，你說你會把什麼告訴我 ？
a：我說我會把金鑰和加密演算法告訴你，...，oh no，直接告訴你太不安全了，告訴你金鑰的代號吧，就叫x，到時候給我代號x就行。至於加密演算法，我只能把介面告訴你，怎麼實現的我得隱藏起來，只要你拿著代號x和資訊來調我這個介面，我就會去找對應的金鑰，並用我的加密演算法來加密你的資訊，哎呀，這剛剛好像說過了，總之我得盡量把這些重要的資訊藏起來，盡量用暗號和你通訊！
b：oh，我好像明白一些了，可是你不擔心我胡亂呼叫嗎？我要是一下給你發成千上萬個呼叫請求，你吃得消嗎？
a：啊呸！都是自己人，何必這樣為難我呢，你不會控制一下嗎？
b：我怕我控制不了我自己啊。。。
a：容我想想，想好了再告訴你。
b：fine，thank u.
a：what？and you?
API介面簽名驗證
系統從外部獲取資料時，通常採用api介面呼叫的方式來實現。請求方和介面提供方之間的通訊過程，有這幾個問題需要考慮 1 請求引數是否被篡改 2 請求 是否合法 3 請求是否具有唯一性。今天跟大家 一下主流的通訊安全解決方案。引數簽名方式 這種方式是主流。它要求呼叫方按照約定好的演算法生成簽名字串，作為...
php介面簽名驗證
在做一些api介面設計時候會遇到設定許可權問題，比如我這個介面只有指定的使用者才能訪問。很多時候api介面是屬於無狀態的，沒辦法獲取session，就不能夠用登入的機制去驗證，那麼 大概的思路是在請求包帶上我們自己構造好的簽名，這個簽名必須滿足下面幾點 a 唯一性，簽名是唯一的，可驗證目標使用者 b...
介面安全 簽名驗證
為防止第三方冒充客戶端請求伺服器，可以採用引數簽名驗證的方法 將請求引數中的各個鍵值對按照key的字串順序公升序排列 大小寫敏感 把key和value拼成一串之後最後加上金鑰，組成key1value1key2value2privatekey的格式，轉成utf 8編碼的位元組序列後計算md5，作為請求...