如何设计B端SDK和API的激活与安全机制？

　　在C端流量红利逐渐消失的今天，很多企业开始转向toB的生意。
　　而B端的生意就离不开SDK和API。这是公司对外输出技术方案必不可少的两种不同的形式。
　　因此，本文将结合SDK和API进行介绍，分析它们的区别以及如何设置激活与安全机制。
　　1。SDK和API的区别
　　首先我们简单来讲一下SDK和API的区别。
　　1。1什么是API？
　　API，全称ApplicationProgrammingInterface，即应用程序编程接口。
　　API其实就是把做好的功能，封装成各种预先定义好的函数，其他人想使用这些已有的功能，只需要调用这些函数，并传递必要的参数即可。
　　API的主要作用是，程序员不需要深究API背后功能实现的具体逻辑，程序员只需要直接调用API就可以使用其背后的功能逻辑，这节省了程序员一大部分的工作，大大提升了效率。
　　举个例子：
　　银行的窗口就类似一个个的API，他们分别有不同的功能，比如取款、存款、对公等业务。
　　而我们预先填好的表格信息，交给窗口的工作人员，就是传递必要的“参数”信息给这个窗口API，然后使用它的存款功能。
　　我们不需要理解工作人员具体需要哪些操作，其中涉及多少复杂逻辑。
　　只需要来到窗口（调用API），上交表格（传递必要信息）就能使用该功能服务。
　　1。2什么是SDK？
　　SDK就是SoftwareDevelopmentKit的缩写，翻译过来软件开发工具包。
　　这是一个覆盖面相当广泛的名词，可以这么说：辅助开发某一类软件的相关文档、范例和工具的集合都可以叫做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，国际移动设备识别码（InternationalMobileEquipmentIdentity，IMEI）
　　IMEI本该最理想的设备ID，具备唯一性，恢复出厂设置不会变化（真正的设备相关）。
　　但是Android6。0以后，就需要用户授权才能使用，而且在Android10。0以后，就会彻底拒绝获取IMEI。
　　并且，IMEI其实只有通讯的设备才会有，如果没有通讯（简单理解，就是电话卡）模块的话，也不一定有IMEI号。
　　序列号（SN）
　　设备序列号由厂商提供，如果厂商比较规范的话，序列号应该是唯一的，也不会随刷机或恢复出厂设置等改变。
　　但是你不能把利益建立在人性的基础上，那太不靠谱。所以序列号，其实更多只能作为辅助信息来进行判断。
　　MAC地址
　　MAC地址一般指蓝牙MAC、WiFiMac或者是两者的拼接。但是获取同样需要权限，而且如果设备没有蓝牙模块，没有WiFi模块的话，也不一定有MAC地址。
　　AndroidID
　　AndroidID是获取门槛最低的，不需要任何权限，64bit的取值范围，唯一性算是很好的了。但是不足之处也很明显：刷机、root、恢复出厂设置等会使得AndroidID改变
　　所以，我们在设计动态注册激活逻辑的时候，就需要考虑到这些情况。
　　动态注册的激活逻辑，就是每次激活的时候，后台记录设备上传的四个设备信息（有的不一定有）。
　　然后每次其他设备激活的时候，就把该要激活的设备信息在已激活的设备信息记录中进行比对，比对的规则有两方面：
　　所上报的设备信息种类是否一致，种类指的是四种设备信息
　　所上报的设备信息是否一致
　　这样的激活逻辑，虽然能保证最大程度的识别出不同的设备，但是会给统计激活设备上（统计是为了收钱）造成麻烦。
　　例如，AndroidID，会随着刷机、恢复出厂设置而改变。这就会成为客户扯皮的点。
　　客户会说：“我并没有更换设备，只是因为设备故障需要刷机或者恢复出厂设置，你就多收我一台设备的钱，当我是冤大头吗？”
　　虽然这可以通过商务的手段去解决，但是还是那句话，客户是霸霸嘛。
　　其实，从上面我们描述四大设备信息的特征来看，AndroidID具有如下优秀属性：
　　一定能获取到；
　　只有刷机操作才会改变，无法人为指定。
　　所以，完全可以以AndroidID作为主要依据，只要AndroidID一致，不管其他参数种类和参数值是否相同，都可以认为是一台设备。
　　我们只需要找出那些，因为刷机或恢复出厂设置导致AndroidID改变的设备，而这些是客户扯皮的主要部分。
　　因此，在我们给设备动态注册的时候，要采用严格的规则，只要有一点不一样，就重新注册设备信息。
　　但是在统计激活的设备信息上，可以根据一定的规则，将具有争议的注册设备信息给统计出来，做到扯皮也是要有准备和技术含量的。
　　SDK和API是公司输出技术的主要手段，而如何设计激活逻辑和安全机制，是保证公司不被白嫖的手段，需要认真和谨慎的考虑。
　　以上内容是在工作中的一些总结，仅供大家参考。