基於簽章演算法且簡單又安全的API授權機制是什麼

筆者以前在做廣告系統時發現對接的大多數平台的廣告系統都是以token方式授權接口，而且這個token是一直不變的，由廣告主提供，可以說這就是裸奔的接口，只不過這種介面對安全性要求不高，這只能防止惡意呼叫以及驗證頻道的身份。

去年筆者寫過一個API統一授權平台，為內部服務開放介面給第三方系統呼叫提供統一的授權管理，除了方便管理介面授權外，沒有其它用途，但卻要花成本部署。這應該是我做的一個最無意義的專案了。

今天介紹的API授權機製或許也是使用較廣泛的一種API介面授權機制，記得筆者以前做微信支付功能的時候，微信提供的支付介面也使用這種方式：簽章。優勢：簡單、不影響效能、不需要額外成本。

這種授權方法的實作邏輯是，授權方為每個存取平台設定唯一的識別碼(key)以及設定獨立金鑰，其實也相當於帳號密碼。要求接入方系統在每次發起請求都在請求頭攜帶三個參數，分別是身份標識(key)、發起請求的時間戳、以及簽名，授權方系統在接收到請求時校驗簽名，校驗透過才放行請求。

校驗簽名的過程為，從請求頭取得key和時間戳，再根據金鑰透過相同演算法產生簽章(呼叫方與授權方使用相同簽章演算法)，最後比較請求頭取得的簽名是否相等，如果是則校驗成功，否則校驗失敗。

基於簽章演算法的授權方法實作過程如下：

授權方：

1.定義簽章演算法，提供簽章產生演算法給接入方，並為接入方生成密鑰和身份標識;

2.在項目中攔截需要驗證簽名的接口，從請求頭獲取時間戳和身份標識，根據密鑰和簽名算法生成簽名，將產生的簽章與從請求頭獲取到的簽章比較，如果相同則繼續步驟3，否則拒絕請求;

3.請求時效性校驗，用目前系統時間戳與從請求頭取得到的時間戳比較，如果請求在有效時間範圍內則放行請求，否則拒絕並回應簽章過期。

存取方：

1.從授權方取得對接文檔，並向授權方要金鑰和身分識別;

2.根據文件提供的簽章產生演算法封裝簽章方法;

3.在發起請求時，將身分識別識別、目前時間戳記寫入請求頭。

簽名產生演算法可自訂，如將身分識別(key)、時間戳記(timestamp)和金鑰拼接在一起後，再採用一種不可逆演算法對字串進行加密產生簽名，如MD5演算法.規則越複雜就越不容易被破解。

簽章加上時間戳記有什麼好處?

一是為簽章加入時效性。授權系統可以限制簽章的有效時間為一秒或五秒，利用請求時間戳記和目前時間戳記進行比較。但要求雙方系統時間必須正確。

二是安全性，如果駭客攔截了你們系統的請求，然後修改請求再發起請求，這期間肯定是要時間的吧，所以當系統接收到篡改後的請求時，簽名的有效期已經過去了。如果變更請求頭傳遞的時間戳，請求的授權方系統將產生不同於請求頭傳遞的簽名，因此請求仍將無效。

如果你不知道金鑰，在了解授權方（肉雞）的簽名規則的前提下，也無法產生有效的簽名。使用非對稱加密演算法簽署的文件，幾乎不可能透過暴力破解破解金鑰。

那為什麼用時間戳而不用格式化時間字串呢?

這可能是考慮時區上的相容吧，不同機房所在時區不同的話，時間就不同，但時間戳都相同。

為發揮這種授權方式的安全性，首先是產生簽章的規則必須夠複雜，然後是簽章的加密演算法要不可逆，千萬不要使用Base64這種演算法，最後是金鑰要夠長夠複雜，以確保即便在知道簽章產生規則的情況下，也不可能透過暴力破解出金鑰。

簽章規則是指產生加密前的簽章字串的規則，例如：規則包含key、金鑰、時間戳，其中key和金鑰會出現兩次。假設key為“app”，金鑰為"123"，時間戳為"1111111111111"，拼接產生的加密前的簽名為"app1231111111111111app123"，最後透過加密演算法對拼接的字串加密演算法對接合的字串加密演算法產生最終的簽章。

每個介面都要寫一次簽章邏輯不麻煩嗎?

不需要。對於授權方，可透過過濾器或攔截器完成簽章驗證邏輯;對於呼叫方，使用不同框架有不同的方法，但我們總是能想到辦法只寫一次簽章邏輯不是嗎?

以上是基於簽章演算法且簡單又安全的API授權機制是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！