好久沒寫博客了，打起字來都不知道怎麼總結文字了。
首先，明白一點，接口只要暴露在公網就沒有了絕對的安全，我們使用https也好，jwt也好還是簽名也罷，都是將我們接口協議被攻擊的成本大大增加，使得黑客或者別有用心之人去衡量攻擊我們的服務收益無限接近於0，但是難度無限增大。
既然是一點思考，那麼必然產生問題？
1.爲什麼去做簽名，或者說他的好處是什麼？
2.簽名怎麼做？
3.簽名和https的區別？
假設我們暴露一個查詢接口到公網，通過app或者web端很容易知道要傳的參數，那麼攻擊者就可以寫腳本去無限請求這個接口造成ddos攻擊。好，加入我們有jwt認證，攻擊者申請賬號後還是正常登錄獲取jwt token繼續請求這個token，此時我們也可以封掉這個ip和請求的賬號，那麼別人使用ip代理呢，別人腳本申請賬號呢？當然這一步步下來總歸是有解決方案的，但是有沒有一種方法是統統解決的呢？
我先不說簽名行不行，我先來說說我認爲的簽名應該怎麼做？
首先我有一對rsa的非對稱加密的私匙和公匙，埋點給客戶端，每次客戶端請求的時候將請求的時間戳和要生成簽名的salt值用公匙去進行非對稱加密成值value，然後用接口需要傳遞的參數、時間戳以及salt按照一定順序進行md5之類的對稱加密生成signature，然後將參數、value以及signature傳給服務端。
服務端先用私匙解密出時間戳和salt，然後用他們按照同樣的方式生成簽名，和客戶端的簽名比對，如果不一樣即拒絕這次請求，甚至可以對時間戳做校驗，時間戳只在一分鐘內有效。
我這樣的做法能否解決上面的被攻擊的問題呢，首先要攻擊我的接口，你必鬚生成符合規定的簽名，就是攻擊者必須知道salt的值以及生成md5簽名的順序，因爲不同字符串的順序md5出來的值不可能相同，而我們的salt是通過rsa非對稱加密解出來的。所以要僞造這個簽名的難度非常大。這樣一來，請求的合法性，唯一性以及參數篡改問題就解決了！
而且我們還可以對上面的方案進行改善，比如多用幾對rsa的公匙和私匙，客戶端隨機使用一對公匙加密，只需要告訴服務端用的是哪對就行，還可以對傳輸參數進行加密，讓攻擊者連傳輸的參數都不知道是什麼！
那麼到這裏不知道大家覺得簽名和https的區別是啥？
我所描述的簽名方案和https一樣也是用非對稱加密協商，用對稱加密傳遞數據，形式上不同的是https不需要提前埋點，而是通過第三方ca證書來進行非對稱協商的。
其實我覺得很簡單，就是https是傳輸通道的防護，簽名是應用層的防護。
簽名保護的是接口不被濫用，沒有簽名，就算https請求接口也可能被隨意無限調用，而https的作用就是保證請求傳遞的過程中不會被中間人攔截獲取到請求的內容從而僞造這次請求去欺騙服務端。
以上是我對於簽名和https一點思考，不是很全面，主觀較強，有些地方描述也可能不到位，請多多指教。