2.1、從登錄驗證說起
在我們內部項目之間進行的接口調用中壹般會用到這種： 用戶登錄->生成token並保存->接口請求驗證token ，這裏也可以把token做成全局的用以單點登錄。
2.2、說說使用token驗證
① 但是如果我們要對接第三方接口或者向第三方提供接口時，這個模式就使用得比較少壹些了。首先，token攜帶在請求中很多時候已經是壹個 明文傳輸 了，有心的話可以直接進行數據提取然後做壹些其他事情(做過爬蟲的應該都很熟練哈)。
② 在第三方接口對接時更多的是以加盟或綁定的形式為主，在接口調用之前 很少會做登錄的動作 ，而且處於安全性考慮這種方式的安全性也有待進壹步提升。
2.3、解決方案
其實這個問題已經是有比較完備的解決方案了得： 雙方約定壹個公鑰，壹個私鑰然後按照特定的算法(MD5、SHA256)進行加密生成壹個簽名 。使用方在接口調用時攜帶簽名及其他數據，提供方在接收到調用時也按照約定進行壹次簽名的生成，最後會比較兩方的數據，如果兩方的簽名壹致則請求檢測初步通過，不符合時則拒絕。
3.1、整體思路
使用特定的簽名算法且使用雙方都進行生成（其參數包含公鑰、時間戳、攜帶參數）。在我這邊接收到請求時先去檢測公鑰是否在我方的約定池中存在，然後校驗 簽名壹致性、有效時間，最後是參數合法性檢測 。其中在中間任何壹個環節出現問題即 拋出對應回執信息 。
PS:部分參數可參與簽名的算法
3.2、簽名算法
在這裏面最重要的就是簽名算法了，其操作步驟如下：
① 使用Map接收參數，然後對按照其中的非空參數名的ACCII碼從小到大進行排序
② 使用URL鍵值對的形式(key1=value1&key2=value2...)進行字符串拼接
③ 在上述生成的字符串上面拼接私鑰得到新的字符串signStr，並對signStr進行SHA256運算得到signShsStr
④ 最後把signShaStr轉換成大寫，得到最終的簽名
4.1、signBuildUtil
4.2、SHA256運算
5.1、在簽名中可以讓部分重要的參數進行參與
5.2、使用時間戳並參與簽名壹方面是增加簽名的預測難度也可以作為時間有效性檢測的依據
5.3、最好是有壹個良好的文檔約定和公鑰、私鑰的良好維護