筆者以前在做廣告系統時發現對接的大多數平臺的廣告系統都是以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″,最后通過加密算法對拼接的字符串加密就能生成最終的簽名。
每個接口都要寫一遍簽名邏輯不麻煩嗎?
不需要。對于授權方,可通過過濾器或者攔截器完成簽名驗證邏輯;對于調用方,使用不同框架有不同的方法,但我們總能想到辦法只寫一次簽名邏輯不是嗎?