上篇文章：《API接口入門（一）：讀懂API接口文檔》已經解釋了什麼是API接口，API接口的基本交互是怎麼樣的？讀完後我們可以知道，API接口應用實際上是系統間通訊的過程，A向B傳輸參數，B向A返回結果。那本章将講解API接口傳輸的簽名和加密。

适合閱讀的人群：産品經理及求職者

本文目錄：

1. API接口為什麼要簽名加密？
2. API接口如何加密？

一、API接口為什麼要簽名加密？

想象一個場景：一位許久不見的好兄弟，突然在微信裡面跟你說“兄弟，借我1萬應急呗”，你會怎麼反應？

我想大部分人馬上的反應就是：是不是被盜号了？他是本人嗎？

實際上這是我們日常生活中常見的通訊行為，系統間調用API和傳輸數據的過程無異于你和朋友間的微信溝通，所有處于開放環境的數據傳輸都是可以被截取，甚至被篡改的。因而數據傳輸存在着極大的危險，所以必須加密。

加密核心解決兩個問題：

1. 你是本人嗎？（簽名驗簽）
2. 你傳過來的信息是對的嗎？（加密解密）

二、API接口如何簽名驗簽和加密解密？

古代人寫信通過郵差傳信，路途遙遠，他們為了避免重要的内容被發現，決定用密文來寫信，比如我想表達“八百标兵上北坡”，我寫成800north，并且收件人也知道怎麼閱讀這份信息，即使路上的人截取偷看了，也看不懂你們在說的什麼意思。同時我在文末簽上我的字迹，在盒子裡放上我的信物（比如一片羽毛等等），這樣收件人也就知道這份信是我寄出的了。

這被稱為“對稱性密碼”，也就是加密的人用A方式加密，解密的人用A方式解密，有什麼缺點呢？

如果你經常傳輸，這就很容易被發現了密碼規律，比如我很快就知道你寄信都會帶上一片羽毛，那我以後也可以搞一片羽毛來冒充你了。加上，如果我要給很多人寄信，我就要跟每個人告訴我的加密方式，說不準有一個卧底就把你的加密方式出賣了。

因為互聯網傳輸的對接方數量和頻率非常高，顯然搞個對稱性密碼是不安全的。于是，基于對稱性密碼延伸出“非對稱密碼”的概念。

1. 公私鑰——簽名驗簽及加解密原理

通俗的解釋：A要給B發信息，B先把一個箱子給A，A收到之後把信放進箱子，然後上鎖，上鎖了之後A自己也打不開，取不出來了，因為鑰匙在B的手裡，這樣即使路上被截取了，别人也打不開箱子看裡面的信息，最後B就能安全地收到A發的信了，并且信息沒有洩露。

現在我們以一個單向的A發信息給B的場景進行深入了解公私鑰工作原理。

1. 發送者和接收者都有2套加解密的方法，而且他們把其中一套加密方法a和解密方法b都公開（虛線标黑）；
2. 這裡提到的加解密，因為密碼學過于深奧，無法解釋。大家需默認加密方法是不能反推出解密方法的，解密方法是不能反推出加密方法的。a加密就必須a解密，b加密就必須b解密；
3. 現在A需要向B發送一條信息，因為信息的内容很重要，他就用接收者B的加密方法c進行加密，這樣隻有B自己的解密方法c才能解開，任何人獲取了都解開不了，包括A自己也解不開；
4. 在A向B發送信息的同時，需要帶上自己的簽名，這個時候A用自己才知道的加密方法b進行加密，因為任何人都知道解密方法b，所以任何人都可以看到A的簽字，也就是任何人都知道這條是A發出來的信息，但因為簽名不是不能公開的信息，所以被解密了也沒有關系。

總結：

（1）簽名會被任何人獲取，但因為簽名内容不涉及核心内容，被獲取破解是OK的。

（2）重要内容隻能接收方解密，任何人獲取了都無法解密。

（3）接收者B隻有驗證簽名者是A的信息，才會執行接下來的程序。阿貓阿狗發來的信息不予執行。

搗局者C可能的情況：

（1）他獲取到這條信息是A發出的，但看不明白加密的内容。

（2）他可以也用接受者B的加密方法c向接收者B發信息，但他無法冒充發送者A的簽名，所以B不會接受C的請求。

（2）公私鑰的非對稱加密 session key對稱加密

2. 公私鑰的非對稱加密 session key對稱加密

上一小節解釋的公私鑰加密是标準和安全的，但因為這類非對稱加密對系統運算的需求比較大，在保證安全的前提下，還是盡量希望提升程序響應的時效。所以目前主流應用的另一種加密方式是公私鑰的非對稱加密 session key對稱加密。

1. 當A向B發送信息的時候，不需要用到B的公私鑰。
2. A用自己的加密方法b加密簽名和一條空信息，因為信息無關重要，被破解了也沒關系，B利用解密方法b驗證了是A發來的信息。
3. 這個時候，接收者B用發送者A的加密方法a，加密一個有時效的加密方法給A（相當于告訴A，這2個小時，我們用這個暗号進行溝通），因為隻有A有解密方法，所以别人獲取了也不能知道session key是什麼。
4. A接收到session key了以後，A用這種有時效的加密函數發送重要信息，簽名仍用加密方法b加密，B用同樣一個加密函數解密（實際上變成了對稱加密，大家都用同樣的方式加解密）
5. 2小時後，再重複第2步，更新加密方法。

3. 總結

（1）當B向A發出臨時有效的加密方法之後，通訊的過程變為了對稱加密；

（2）這類加密方式的核心是時效性，必須在短時間内更新，否則固定的規律容易被獲取破解。

搗局者C可能的情況：

（1）他獲取到B發出的session key的加密文件，無法破解session key是什麼。因為解密方法在A手上；

（2）通過各種手段，C破解出session key的加解密方法，但因為時效已到，session key更新，C徒勞無功；

（3）C在時效内破解出session key，但無法冒充A的簽名。

以上是2種常見的加解密方式，每個開放平台會在概述中最開始介紹API調用的安全加解密方法，這是每個對接過程中必須的準備流程，如微信企業平台在概述中就已介紹利用第2種方法（企業微信命名為access_token）進行加解密傳輸。

三、最後

以上就是API簽名驗簽和加解密的基本原理，接下來我會繼續更新API的請求方式等問題，同時以企業微信，微信開放平台等大型開放平台的業務解釋各平台支持的現有功能。

綜上，水平有限，如有纰漏，敬請指出。

作者：就是愛睡覺；已任職電商和金融業行業的産品崗位3年時間，目前業務以TO B業務為主，文章是用于記錄自己在産品工作的思考和想法，希望有想法的小夥伴共同交流。

本文由 @就是愛睡覺 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,