扶前新闻网>军事>藏金阁亿游_如何设计B端SDK和API的激活与安全机制?

藏金阁亿游_如何设计B端SDK和API的激活与安全机制?-扶前新闻网

2020-01-11 12:57:37 阅读:4991

藏金阁亿游_如何设计B端SDK和API的激活与安全机制?

藏金阁亿游,在c端流量红利逐渐消失的今天,很多企业开始转向 to b的生意。

而b端的生意就离不开sdk和api。这是公司对外输出技术方案必不可少的两种不同的形式。

因此,本文将结合sdk和api进行介绍,分析它们的区别以及如何设置激活与安全机制。

首先我们简单来讲一下sdk和api的区别。

api,全称application programming interface,即应用程序编程接口。

api其实就是把做好的功能,封装成各种预先定义好的函数,其他人想使用这些已有的功能,只需要调用这些函数,并传递必要的参数即可。

api的主要作用是,程序员不需要深究api背后功能实现的具体逻辑,程序员只需要直接调用api就可以使用其背后的功能逻辑,这节省了程序员一大部分的工作,大大提升了效率。

举个例子:

银行的窗口就类似一个个的api,他们分别有不同的功能,比如取款、存款、对公等业务。

而我们预先填好的表格信息,交给窗口的工作人员,就是传递必要的“参数”信息给这个窗口api,然后使用它的存款功能。

我们不需要理解工作人员具体需要哪些操作,其中涉及多少复杂逻辑。

只需要来到窗口(调用api),上交表格(传递必要信息)就能使用该功能服务。

sdk 就是 software development kit 的缩写,翻译过来——软件开发工具包。

这是一个覆盖面相当广泛的名词,可以这么说:辅助开发某一类软件的相关文档、范例和工具的集合都可以叫做sdk。

sdk可以简单的认为是一系列api的程序包集合。在这个程序包中是一个完整的软件功能,这份程序包几乎是全封闭的,只有一个小小接口(api)可以联通外界。

还是刚刚银行的例子:

可以把银行看做是一整个sdk,银行sdk程序包能帮你完成存款、取款等业务。

银行sdk唯一联通外界的就是它的大门,或者说是取号机(api),只有进入银行然后取号,才能在不同的窗口办理服务。

而这些不同的窗口,就可以看成一个个不同功能的api接口。

安全机制,其实是为了保护我方后台,主要有两点:

先来简单说一下api的接入安全机制。

api的安全机制设计主要考虑两个方面:

第一个方面,需要客户对自家的后台做一层封装,然后我们后台仅接受客户后台接口传递的请求。

第二个方面,需要在我方后台建立ip白名单,提供给客户后台,方便双方进行加密验证。识别哪些是客户的请求,哪些是恶意请求。

为了防止客户拿到我们的sdk以后白嫖,或者为所欲为,我们需要在客户接入sdk,请求我方服务的时候进行激活校验。

就像是我们买票进站乘车一样,需要出示身份证和车票进行校验方可通过。

sdk最终都是会被集成到硬件设备中提供服务,尤其是ai公司的技术方案,不管是视觉还是语音,最后交付的都是硬件产品。

通常激活的时机,都是在硬件设备进行第一次启动的时候进行。

sdk的激活涉及到我方对客户的计费,所以激活逻辑的设计要非常的仔细和严谨(毕竟都是钱哪。。)

一般来说,sdk的激活方案可以分为三种(以下说法参考思必驰的产品授权方案):

预烧录,指的是,我们后台预先生成授权的license文件,然后预先写入硬件设备的存储文件中。在设备首次启动的时候,就直接调取license文件进行激活。这种方式适用于需要不联网提供服务的场景。

预登记,指的是,预先登记设备白名单,以用户设备注册激活的一种授权方式。这种方式适用于客户提前知道所需授权设备的设备标识的场景

动态注册,指的是,每次设备激活,后台动态给这些设备进行激活并注册的一种形式。这种方式适用于客户可以提供设备的唯一标识,但是提前不知道哪些设备需要授权,不知道有多少设备需要授权的场景。

下面想主要讲一下,我在设计预登记和动态注册时遇到的一些坑。

预登记方式其实对我方来说是比较友好的,因为客户提前提供准确的设备唯一标识的时候,我们可以很方面的进行激活和统计,说直白点,就是方便收钱。

所以,客户为了省钱,有可能采取作弊策略:将一个设备的唯一标识给多台设备进行使用。

因为设备标识,一般是设备序列号(sn),对于硬件厂商来说是可以自己按照一定的规则随便刷的。

那为了防止被客户白嫖,我们自然要设计一套防作弊策略:不仅仅采集客户提供的设备序列号,还要采集一些设备的其他信息进行辅助判断,该序列号只绑定了一台设备。

当客户想白嫖我们,将设备a的序列号给设备b使用,那么在激活校验的时候,就会发现设备b的序列号关联的信息和我们记录的信息(设备a)不同,如此就可以认定客户是想白嫖,激活失败。

上述方式看起来比较完美的解决了客户作弊的问题。但是对于部分客户来说就会造成不便。

有些客户在对接sdk后,会进行测试。在测试的过程中,客户会不断的对硬件设备进行刷机、恢复出厂设置等骚操作。

而刷机、恢复出厂设置会改变设备的信息(例如androidid),那么就会造成同样的序列号在同一台设备上不能激活了。

因为刷机改变了它的设备信息,我们会认为这不是同一台设备。

你可能会说,那客户再写一个序列号不就行了,反正客户可以自己刷序列号。

客户是上帝,你不能指望客户去干这样的累活。当然是我们来优化了。

为了解决这个问题,我们想到一个方案:超级序列号。这个序列号必须是我们来生成(可控),拥有无限次激活,可以在多台设备上使用的超能力。

但是为了防止客户拿这个超级序列号白嫖我们,我们需要给这个超级序列号设置时间限制。在有效时间内可以随意使用,一旦过了有效期就会失效。

动态注册就是在设备第一次启动激活的时候,上传设备的信息,包括:序列号、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协议