如何設計B端SDK和API的啟用與安全機制？

在C端流量紅利逐漸消失的今天，很多企業開始轉向 to B的生意。

而B端的生意就離不開SDK和API。這是公司對外輸出技術方案必不可少的兩種不同的形式。

因此，本文將結合SDK和API進行介紹，分析它們的區別以及如何設定啟用與安全機制。

1。 SDK和API的區別

首先我們簡單來講一下SDK和API的區別。

1。1 什麼是API？

API，全稱Application Programming Interface，即應用程式程式設計介面。

API其實就是把做好的功能，封裝成各種預先定義好的函式，其他人想使用這些已有的功能，只需要呼叫這些函式，並傳遞必要的引數即可。

API的主要作用是，程式設計師不需要深究API背後功能實現的具體邏輯，程式設計師只需要直接呼叫API就可以使用其背後的功能邏輯，這節省了程式設計師一大部分的工作，大大提升了效率。

舉個例子：

銀行的視窗就類似一個個的API，他們分別有不同的功能，比如取款、存款、對公等業務。

而我們預先填好的表格資訊，交給視窗的工作人員，就是傳遞必要的“引數”資訊給這個視窗API，然後使用它的存款功能。

我們不需要理解工作人員具體需要哪些操作，其中涉及多少複雜邏輯。

只需要來到視窗（呼叫API），上交表格（傳遞必要資訊）就能使用該功能服務。

1。2 什麼是SDK？

SDK 就是 Software Development Kit 的縮寫，翻譯過來——軟體開發工具包。

這是一個覆蓋面相當廣泛的名詞，可以這麼說：輔助開發某一類軟體的相關文件、範例和工具的集合都可以叫做SDK。

SDK可以簡單的認為是一系列API的程式包集合。在這個程式包中是一個完整的軟體功能，這份程式包幾乎是全封閉的，只有一個小小介面（API）可以聯通外界。

還是剛剛銀行的例子：

可以把銀行看做是一整個SDK，銀行SDK程式包能幫你完成存款、取款等業務。

銀行SDK唯一聯通外界的就是它的大門，或者說是取號機（API），只有進入銀行然後取號，才能在不同的視窗辦理服務。

而這些不同的視窗，就可以看成一個個不同功能的API介面。

2。 API的接入安全機制

安全機制，其實是為了保護我方後臺，主要有兩點：

不被不明身份者訪問

不被惡意大量的請求攻擊

先來簡單說一下API的接入安全機制。

API的安全機制設計主要考慮兩個方面：

API接入方案如何避免介面盜用（防止不明身份者訪問）

Http介面請求如何避免攻擊（防止被惡意大量請求攻擊）

第一個方面，需要客戶對自家的後臺做一層封裝，然後我們後臺僅接受客戶後臺介面傳遞的請求。

第二個方面，需要在我方後臺建立IP白名單，提供給客戶後臺，方便雙方進行加密驗證。識別哪些是客戶的請求，哪些是惡意請求。

3。 SDK的接入安全機制

為了防止客戶拿到我們的SDK以後白嫖，或者為所欲為，我們需要在客戶接入SDK，請求我方服務的時候進行啟用校驗。

就像是我們買票進站乘車一樣，需要出示身份證和車票進行校驗方可透過。

SDK最終都是會被整合到硬體裝置中提供服務，尤其是AI公司的技術方案，不管是視覺還是語音，最後交付的都是硬體產品。

通常啟用的時機，都是在硬體裝置進行第一次啟動的時候進行。

SDK的啟用涉及到我方對客戶的計費，所以啟用邏輯的設計要非常的仔細和嚴謹（畢竟都是錢哪。。）

一般來說，SDK的啟用方案可以分為三種（以下說法參考思必馳的產品授權方案）：

預燒錄

預登記

動態註冊

預燒錄，指的是，我們後臺預先生成授權的license檔案，然後預先寫入硬體裝置的儲存檔案中。

在裝置首次啟動的時候，就直接調取license檔案進行啟用。這種方式適用於需要不聯網提供服務的場景。

預登記，指的是，預先登記裝置白名單，以使用者設備註冊啟用的一種授權方式

。這種方式適用於客戶提前知道所需授權裝置的裝置標識的場景

動態註冊，指的是，每次裝置啟用，後臺動態給這些裝置進行啟用並註冊的一種形式

。這種方式適用於客戶可以提供裝置的唯一標識，但是提前不知道哪些裝置需要授權，不知道有多少裝置需要授權的場景。

下面想主要講一下，我在設計預登記和動態註冊時遇到的一些坑。

3。1 預登記對我方友好，但是對客戶不太靈活

預登記方式其實對我方來說是比較友好的，因為客戶提前提供準確的裝置唯一標識的時候，我們可以很方面的進行啟用和統計，說直白點，就是方便收錢。

所以，客戶為了省錢，有可能採取作弊策略：

將一個裝置的唯一標識給多臺裝置進行使用

。

因為裝置標識，一般是裝置序列號（SN），對於硬體廠商來說是可以自己按照一定的規則隨便刷的。

那為了防止被客戶白嫖，我們自然要設計一套防作弊策略：

不僅僅採集客戶提供的裝置序列號，還要採集一些裝置的其他資訊進行輔助判斷，該序列號只綁定了一臺裝置

。

當客戶想白嫖我們，將裝置A的序列號給裝置B使用，那麼在啟用校驗的時候，就會發現裝置B的序列號關聯的資訊和我們記錄的資訊（裝置A）不同，如此就可以認定客戶是想白嫖，啟用失敗。

上述方式看起來比較完美的解決了客戶作弊的問題。但是對於部分客戶來說就會造成不便。

有些客戶在對接SDK後，會進行測試。在測試的過程中，客戶會不斷的對硬體裝置進行刷機、恢復出廠設定等騷操作。

而刷機、恢復出廠設定會改變裝置的資訊（例如AndroidID），那麼就會造成同樣的序列號在同一臺裝置上不能激活了。

因為刷機改變了它的裝置資訊，我們會認為這不是同一臺裝置。

你可能會說，那客戶再寫一個序列號不就行了，反正客戶可以自己刷序列號。

客戶是上帝，你不能指望客戶去幹這樣的累活。當然是我們來優化了。

為了解決這個問題，我們想到一個方案：

超級序列號

。這個序列號必須是我們來生成（可控），

擁有無限次啟用，可以在多臺裝置上使用的超能力

。

但是為了防止客戶拿這個超級序列號白嫖我們，我們需要給這個超級序列號設定

時間限制

。在有效時間內可以隨意使用，一旦過了有效期就會失效。

3。2 動態註冊雖然靈活，但是對於統計來說麻煩

動態註冊就是在裝置第一次啟動啟用的時候，上傳裝置的資訊，包括：

序列號、MAC（藍芽+WiFi）、IMEI和AndroidID

。

但是這些資訊不一定能獲取到。

IMEI，國際移動裝置識別碼（International Mobile Equipment Identity，IMEI）

IMEI本該最理想的裝置ID，具備唯一性，恢復出廠設定不會變化（真正的裝置相關）。

但是Android6。0以後，就需要使用者授權才能使用，而且在Android10。0以後，就會徹底拒絕獲取IMEI。

並且，IMEI其實只有通訊的裝置才會有，如果沒有通訊（簡單理解，就是電話卡）模組的話，也不一定有IMEI號。

序列號（SN）

裝置序列號由廠商提供，如果廠商比較規範的話，序列號應該是唯一的，也不會隨刷機或恢復出廠設定等改變。

但是你不能把利益建立在人性的基礎上，那太不靠譜。所以序列號，其實更多隻能作為輔助資訊來進行判斷。

MAC地址

MAC地址一般指藍芽MAC、WiFi Mac或者是兩者的拼接。但是獲取同樣需要許可權，而且如果裝置沒有藍芽模組，沒有WiFi模組的話，也不一定有MAC地址。

Android ID

Android ID 是獲取門檻最低的，不需要任何許可權，64bit 的取值範圍，唯一性算是很好的了。但是不足之處也很明顯：刷機、root、恢復出廠設定等會使得 Android ID 改變

所以，我們在設計動態註冊啟用邏輯的時候，就需要考慮到這些情況。

動態註冊的啟用邏輯，就是每次啟用的時候，後臺記錄裝置上傳的四個裝置資訊（有的不一定有）。

然後每次其他裝置啟用的時候，就把該要啟用的裝置資訊在已啟用的裝置資訊記錄中進行比對，比對的規則有兩方面：

所上報的裝置資訊種類是否一致，種類指的是四種裝置資訊

所上報的裝置資訊是否一致

這樣的啟用邏輯，雖然能保證最大程度的識別出不同的裝置，但是會給統計啟用裝置上（統計是為了收錢）造成麻煩。

例如，AndroidID，會隨著刷機、恢復出廠設定而改變。這就會成為客戶扯皮的點。

客戶會說：“我並沒有更換裝置，只是因為裝置故障需要刷機或者恢復出廠設定，你就多收我一臺裝置的錢，當我是冤大頭嗎？”

雖然這可以透過商務的手段去解決，但是還是那句話，客戶是霸霸嘛。

其實，從上面我們描述四大裝置資訊的特徵來看，AndroidID具有如下優秀屬性：

一定能獲取到；

只有刷機操作才會改變，無法人為指定。

所以，完全可以以AndroidID作為主要依據，只要AndroidID一致，不管其他引數種類和引數值是否相同，都可以認為是一臺裝置。

我們只需要找出那些，因為刷機或恢復出廠設定導致AndroidID改變的裝置，而這些是客戶扯皮的主要部分。

因此，在我們給裝置動態註冊的時候，要採用嚴格的規則，只要有一點不一樣，就重新註冊裝置資訊。

但是在統計啟用的裝置資訊上，可以根據一定的規則，將具有爭議的註冊裝置資訊給統計出來，做到扯皮也是要有準備和技術含量的。

SDK 和 API 是公司輸出技術的主要手段，而如何設計啟用邏輯和安全機制，是保證公司不被白嫖的手段，需要認真和謹慎的考慮。

以上內容是在工作中的一些總結，僅供大家參考。

本文由 @Jarvan 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議