上篇文章：《API接口入門(mén)（一）：讀懂API接口文檔》已經(jīng)解釋了什么是API接口，API接口的基本交互是怎么樣的？讀完后我們可以知道，API接口應(yīng)用實(shí)際上是系統(tǒng)間通訊的過(guò)程，A向B傳輸參數(shù)，B向A返回結(jié)果。那本章將講解API接口傳輸?shù)暮灻图用堋?/p>

適合閱讀的人群：產(chǎn)品經(jīng)理及求職者

本文目錄：

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

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

想象一個(gè)場(chǎng)景：一位許久不見(jiàn)的好兄弟，突然在微信里面跟你說(shuō)“兄弟，借我1萬(wàn)應(yīng)急唄”，你會(huì)怎么反應(yīng)？

我想大部分人馬上的反應(yīng)就是：是不是被盜號(hào)了？他是本人嗎？

實(shí)際上這是我們?nèi)粘Ｉ钪谐Ｒ?jiàn)的通訊行為，系統(tǒng)間調(diào)用API和傳輸數(shù)據(jù)的過(guò)程無(wú)異于你和朋友間的微信溝通，所有處于開(kāi)放環(huán)境的數(shù)據(jù)傳輸都是可以被截取，甚至被篡改的。因而數(shù)據(jù)傳輸存在著極大的危險(xiǎn)，所以必須加密。

加密核心解決兩個(gè)問(wèn)題：

1. 你是本人嗎？（簽名驗(yàn)簽）
2. 你傳過(guò)來(lái)的信息是對(duì)的嗎？（加密解密）

二、API接口如何簽名驗(yàn)簽和加密解密？

古代人寫(xiě)信通過(guò)郵差傳信，路途遙遠(yuǎn)，他們?yōu)榱吮苊庵匾膬?nèi)容被發(fā)現(xiàn)，決定用密文來(lái)寫(xiě)信，比如我想表達(dá)“八百標(biāo)兵上北坡”，我寫(xiě)成800north，并且收件人也知道怎么閱讀這份信息，即使路上的人截取偷看了，也看不懂你們?cè)谡f(shuō)的什么意思。同時(shí)我在文末簽上我的字跡，在盒子里放上我的信物（比如一片羽毛等等），這樣收件人也就知道這份信是我寄出的了。

這被稱(chēng)為“對(duì)稱(chēng)性密碼”，也就是加密的人用A方式加密，解密的人用A方式解密，有什么缺點(diǎn)呢？

如果你經(jīng)常傳輸，這就很容易被發(fā)現(xiàn)了密碼規(guī)律，比如我很快就知道你寄信都會(huì)帶上一片羽毛，那我以后也可以搞一片羽毛來(lái)冒充你了。加上，如果我要給很多人寄信，我就要跟每個(gè)人告訴我的加密方式，說(shuō)不準(zhǔn)有一個(gè)臥底就把你的加密方式出賣(mài)了。

因?yàn)榛ヂ?lián)網(wǎng)傳輸?shù)膶?duì)接方數(shù)量和頻率非常高，顯然搞個(gè)對(duì)稱(chēng)性密碼是不安全的。于是，基于對(duì)稱(chēng)性密碼延伸出“非對(duì)稱(chēng)密碼”的概念。

1. 公私鑰——簽名驗(yàn)簽及加解密原理

通俗的解釋?zhuān)篈要給B發(fā)信息，B先把一個(gè)箱子給A，A收到之后把信放進(jìn)箱子，然后上鎖，上鎖了之后A自己也打不開(kāi)，取不出來(lái)了，因?yàn)殍€匙在B的手里，這樣即使路上被截取了，別人也打不開(kāi)箱子看里面的信息，最后B就能安全地收到A發(fā)的信了，并且信息沒(méi)有泄露。

現(xiàn)在我們以一個(gè)單向的A發(fā)信息給B的場(chǎng)景進(jìn)行深入了解公私鑰工作原理。

1. 發(fā)送者和接收者都有2套加解密的方法，而且他們把其中一套加密方法a和解密方法b都公開(kāi)（虛線(xiàn)標(biāo)黑）；
2. 這里提到的加解密，因?yàn)槊艽a學(xué)過(guò)于深?yuàn)W，無(wú)法解釋。大家需默認(rèn)加密方法是不能反推出解密方法的，解密方法是不能反推出加密方法的。a加密就必須a解密，b加密就必須b解密；
3. 現(xiàn)在A需要向B發(fā)送一條信息，因?yàn)樾畔⒌膬?nèi)容很重要，他就用接收者B的加密方法c進(jìn)行加密，這樣只有B自己的解密方法c才能解開(kāi)，任何人獲取了都解開(kāi)不了，包括A自己也解不開(kāi)；
4. 在A向B發(fā)送信息的同時(shí)，需要帶上自己的簽名，這個(gè)時(shí)候A用自己才知道的加密方法b進(jìn)行加密，因?yàn)槿魏稳硕贾澜饷芊椒╞，所以任何人都可以看到A的簽字，也就是任何人都知道這條是A發(fā)出來(lái)的信息，但因?yàn)楹灻皇遣荒芄_(kāi)的信息，所以被解密了也沒(méi)有關(guān)系。

總結(jié)：

（1）簽名會(huì)被任何人獲取，但因?yàn)楹灻麅?nèi)容不涉及核心內(nèi)容，被獲取破解是OK的。

（2）重要內(nèi)容只能接收方解密，任何人獲取了都無(wú)法解密。

（3）接收者B只有驗(yàn)證簽名者是A的信息，才會(huì)執(zhí)行接下來(lái)的程序。阿貓阿狗發(fā)來(lái)的信息不予執(zhí)行。

搗局者C可能的情況：

（1）他獲取到這條信息是A發(fā)出的，但看不明白加密的內(nèi)容。

（2）他可以也用接受者B的加密方法c向接收者B發(fā)信息，但他無(wú)法冒充發(fā)送者A的簽名，所以B不會(huì)接受C的請(qǐng)求。

（2）公私鑰的非對(duì)稱(chēng)加密+session key對(duì)稱(chēng)加密

2. 公私鑰的非對(duì)稱(chēng)加密+session key對(duì)稱(chēng)加密

上一小節(jié)解釋的公私鑰加密是標(biāo)準(zhǔn)和安全的，但因?yàn)檫@類(lèi)非對(duì)稱(chēng)加密對(duì)系統(tǒng)運(yùn)算的需求比較大，在保證安全的前提下，還是盡量希望提升程序響應(yīng)的時(shí)效。所以目前主流應(yīng)用的另一種加密方式是公私鑰的非對(duì)稱(chēng)加密+session key對(duì)稱(chēng)加密。

1. 當(dāng)A向B發(fā)送信息的時(shí)候，不需要用到B的公私鑰。
2. A用自己的加密方法b加密簽名和一條空信息，因?yàn)樾畔o(wú)關(guān)重要，被破解了也沒(méi)關(guān)系，B利用解密方法b驗(yàn)證了是A發(fā)來(lái)的信息。
3. 這個(gè)時(shí)候，接收者B用發(fā)送者A的加密方法a，加密一個(gè)有時(shí)效的加密方法給A（相當(dāng)于告訴A，這2個(gè)小時(shí)，我們用這個(gè)暗號(hào)進(jìn)行溝通），因?yàn)橹挥蠥有解密方法，所以別人獲取了也不能知道session key是什么。
4. A接收到session key了以后，A用這種有時(shí)效的加密函數(shù)發(fā)送重要信息，簽名仍用加密方法b加密，B用同樣一個(gè)加密函數(shù)解密（實(shí)際上變成了對(duì)稱(chēng)加密，大家都用同樣的方式加解密）
5. 2小時(shí)后，再重復(fù)第2步，更新加密方法。

3. 總結(jié)

（1）當(dāng)B向A發(fā)出臨時(shí)有效的加密方法之后，通訊的過(guò)程變?yōu)榱藢?duì)稱(chēng)加密；

（2）這類(lèi)加密方式的核心是時(shí)效性，必須在短時(shí)間內(nèi)更新，否則固定的規(guī)律容易被獲取破解。

搗局者C可能的情況：

（1）他獲取到B發(fā)出的session key的加密文件，無(wú)法破解session key是什么。因?yàn)榻饷芊椒ㄔ贏手上；

（2）通過(guò)各種手段，C破解出session key的加解密方法，但因?yàn)闀r(shí)效已到，session key更新，C徒勞無(wú)功；

（3）C在時(shí)效內(nèi)破解出session key，但無(wú)法冒充A的簽名。

以上是2種常見(jiàn)的加解密方式，每個(gè)開(kāi)放平臺(tái)會(huì)在概述中最開(kāi)始介紹API調(diào)用的安全加解密方法，這是每個(gè)對(duì)接過(guò)程中必須的準(zhǔn)備流程，如微信企業(yè)平臺(tái)在概述中就已介紹利用第2種方法（企業(yè)微信命名為access_token）進(jìn)行加解密傳輸。

三、最后

以上就是API簽名驗(yàn)簽和加解密的基本原理，接下來(lái)我會(huì)繼續(xù)更新API的請(qǐng)求方式等問(wèn)題，同時(shí)以企業(yè)微信，微信開(kāi)放平臺(tái)等大型開(kāi)放平臺(tái)的業(yè)務(wù)解釋各平臺(tái)支持的現(xiàn)有功能。

綜上，水平有限，如有紕漏，敬請(qǐng)指出。

作者：就是愛(ài)睡覺(jué)；已任職電商和金融業(yè)行業(yè)的產(chǎn)品崗位3年時(shí)間，目前業(yè)務(wù)以TO B業(yè)務(wù)為主，文章是用于記錄自己在產(chǎn)品工作的思考和想法，希望有想法的小伙伴共同交流。

本文由 @就是愛(ài)睡覺(jué) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議