一、前言

近年來，以API提供服務的方式已經越來越普遍，從前後端分離到Open API，從自己系統呼叫到開放讓其他系統，甚至外部系統呼叫，在提供開放與便利的服務背後，也帶來了安全上的風險。

因此，在設計API的架構時，如何做到安全防護就是個很重要的議題，一般而言，我們都會透過認證後發放Token，各API再藉由驗證Token來辨識呼叫API的用戶端身分以及確認用戶端是否有呼叫此API的權限等管控。

但這樣的防護其實是不足的，我們如何確認資料內容是否有被竄改以及Token是否有被第三方冒用，是接下來本文章所要介紹的部份。

二、訊息摘要

透過密碼雜湊函式將輸入的訊息，輸出為另一段訊息，通常稱輸出的結果為訊息摘要(Message digest)，而且輸出的結果，很難回推所輸入的資料是什麼。

而雜湊函式當中的演算法，因為MD5、SHA-0、SHA-1已相繼被破解，目前普遍使用SHA-2，其中還可細分為SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256等產生摘要長度不同的演算法。

實務上，可將API完整本文再加上特定欄位內容來產生特有的訊息摘要，由用戶端產生後並帶入至Http Header中(註)。

系統使用同樣的規則對送上來的訊息產生摘要、比對摘要，藉以驗證所收到的訊息是否有被竄改，驗證訊息的完整性。

註：放置於Http Header是為了不影響訊息本文，可直接使用完整本文產生訊息摘要。

三、訊息鑑別碼

透過加入訊息摘要的方式，也僅能驗證訊息的完整性，若API是對外公開，也還是可能被未授權的第三方竄改，並重新計算訊息摘要來欺騙系統。

這個時候，可以改採用訊息鑑別碼，即為Message authentication code，縮寫為MAC，也稱為訊息驗證碼，常用的演算法為HMAC，在此演算法中，需結合一個密鑰進行雜湊函式。

1.        在建立用戶端密碼時，一併產生另一組用戶端密鑰(建議此密鑰需固定時間更換)

2.        用戶端在傳送訊息時，使用密鑰透過HMAC的演算法對訊息本文計算出mac值，並帶入Http header當中。

3.        系統收到訊息後，取出此用戶的密鑰，透過HMAC的演算法對訊息本文計算出mac值，並比對用戶送上來的mac值。

此作法除了可確保訊息的完整性外，因雜湊函式包含用戶特有的密鑰，亦可作為身分驗證之用。

由 Twisp, based on diagram by w:User:Smilerpt - self-made,本向量圖形使用Inkscape創作。, 公有領域, https://commons.wikimedia.org/w/index.php?curid=3410890

四、數位簽章

數位簽章是依靠公鑰加密技術來產生，也稱為非對稱式加密技術，不同的是，用戶端使用私鑰將訊息內容加密產生數位簽章，而驗證系統透過公鑰進行解密。

私鑰需透過第三方憑證機構申請憑證而取得，除了確保訊息完整性及身分認證外，還多了一項不可否認性。

通常這種作法，在系統端環境還需額外建置與憑證機構相關的服務，以儲存管理憑證，並提供數位簽章驗證等服務。

五、總結

以上所提到的三種方式，都是用來確認訊息完整性的方法，並沒有哪種方式才是正確的作法，而是要依據專案性質及客戶端環境來選擇最適當的作法。

六、參考資料

MD5 wiki：https://zh.wikipedia.org/wiki/MD5

SHA-2 wiki：https://zh.wikipedia.org/wiki/SHA-2

MAC(訊息鑑別碼) wiki：https://zh.wikipedia.org/wiki/%E8%A8%8A%E6%81%AF%E9%91%91%E5%88%A5%E7%A2%BC

金鑰雜湊訊息鑑別碼 wiki：https://zh.wikipedia.org/wiki/%E9%87%91%E9%91%B0%E9%9B%9C%E6%B9%8A%E8%A8%8A%E6%81%AF%E9%91%91%E5%88%A5%E7%A2%BC

數位簽章wiki：https://zh.wikipedia.org/wiki/%E6%95%B8%E4%BD%8D%E7%B0%BD%E7%AB%A0

電子簽章法：http://www.mantraco.com.tw/e-signature.htm