传感器api 如何设计API产品的认证部分？

发布时间：2024-10-07 00:10:03

如何设计API产品的认证部分？

API产品的认证部分应该如何设计？本文结合作者自己的工作实践经历，对身份验证、对称签名身份验证、非对称加密的签名认证三种方式进行了分析，与大家分享。

做平台产品，绕不开API。当然API也需要伴侣，就是SDK。SDK可以把API的多次交互封装起来，让用户（开发者）只需要调用一个方法，就能完成一个需要多次调用API的业务。

在使用API的时候，它必须知道是谁来使用这个API，这就需要身份认证。最常见的身份认证，是通过账户密码登陆网站。不过现在这种操作越来越少了，现在主流的登陆方式，要么是手机验证码登陆，要么是微信扫码登陆，要么是调用其他账号的登陆。

先来看看传统登陆方式，数据库存放用户名和密码。

假设，用户名为tom，密码为123456。则用户登陆时，把tom和123456 POST到服务器。服务器去数据库里一找，发现有tom，密码也确实是123456，那么就登陆成功，也就是完成了身份认证。

这是典型的明文账户系统。它最大的缺点，是不安全。一旦数据库泄露，就知道了用户的密码，这个时候，就可以去撞库（用tom的密码123456去登陆tom在别的网站的账号）。

有时候，明文保存密码是黑客特意设置的，黑客设置一个网站吸引别人用邮箱去注册，明文保存了用户的密码。

为了安全起见，数据库采用加密的方式保存密码，而且一定是单项的，只能加密，不能解密。

如上图所示，这是经过md5处理的密码。当用户登陆的时候，发送用户名和经过md5处理的密码，后台去数据库里查询，查询到了说明登陆成功，否则就是登陆失败。

这样的好处是，黑客嗅探出了你的密码，也仅仅能登陆你登陆的这个网站，他不能还原出你加密前的明文，也就无法去撞库。即便网站数据库泄露了，也很难知道你真正的密码。

但是，现在有一些md5搜集器，搜集了很多明文密码，并使用md5加密后存在数据库里。

这样，如果你的密码是常规的密码，则很容易被逆向（查询）出来。比如：

它很容易就能查出你的原始密码，它仅仅是查询，而不是破解。因为有大量的常规的普遍的密码和加密后的md5被存进去。

如果想进一步安全，怎么办？办法也是有的，那就是使用公私钥的方式。

用户登陆，系统产生一个随机数，发送给用户。用户需要使用私钥对这个随机数进行签名，发给系统。系统用公钥验签，完成身份认证。

虽然这种方法安全，但是认证时间长，对服务器造成的压力也很大。在做产品设计的时候，成本因素也是一个必须考虑的问题，包括时间成本，服务器算力成本等。

这需要产品经理根据应用场景及安全级别去评估，取舍。而不是一味的选择更安全的系统。

刚才提到的是用户身份验证。而API中，更多的操作，是针对某个产品的权限的。

如上图所示，一个用户可以创建多个项目，每个项目都有一个key。我们假设，应用1用的是简单身份验证，应用1的key是一个具备一定长度的字符串。任何人只要知道这个字符串，就可以对其进行操作。

应用2比应用1安全一些，采用的是keyID+keySecret的方式，也就是hmac-sha256签名机制。它会用密钥对keyID、调用的API、参数、时间等进行签名，因为服务器也有一个相同的keySecret，可以用来验证签名，以确定身份。

应用3就是更安全的，它有keyID和keyPubkey，即公钥。调用的时候，使用私钥对API、方法、参数、时间等进行签名，服务器使用私钥对应的公钥对签名进行验签，但时间会长一些。

总结一下，通常API身份验证有两种：简单身份验证，和签名身份验证。下面举例子，说明哪些领域使用哪些身份验证方法。

通常情况而言，使用javascript调用的API，基本上使用的是简单身份验证，而且用的是url传key的方式。比如，百度地图的key，在调用的时候，是直接构建在url里的：

这意味着，你的key很容易泄露。比如，稍微懂前端的，就可以从源码里看到你的key。以及，懂点网络嗅探的，也能轻而易举能得到key。因此对于简单身份验证，还需要一个ip或域名白名单进行配合。这样，即便别人获得了你的key，也无法使用你的key，除非他同时入侵了你的服务器，在你的ip上面进行操作。

post传key和header传key没有本质上的区别。例如，remove.bg 的API，使用的是headers传递key，它也是简单身份验证，没有进行签名。

$ curl -H 'X-API-Key: YOUR_API_KEY' \ -F 'image_file=@/path/to/file.jpg' \ -f https://api.remove.bg/v1.0/removebg -o no-bg.png

而微信的API，则需要签名。如微信支付的签名算法：

第一步，设所有发送或者接收到的数据为集合M，将集合M内非空参数值的参数按照参数名ASCII码从小到大排序（字典序），使用URL键值对的格式（即key1=value1&key2=value2…）拼接成字符串stringA。特别注意以下重要规则：

参数名ASCII码从小到大排序（字典序）；如果参数的值为空不参与签名；参数名区分大小写；验证调用返回或微信主动通知签名时，传送的sign参数不参与签名，将生成的签名与该sign值作校验。微信接口可能增加字段，验证签名时必须支持增加的扩展字段

第二步，在stringA最后拼接上key得到stringSignTemp字符串，并对stringSignTemp进行MD5运算，再将得到的字符串所有字符转换为大写，得到sign值signValue。

微信支付的验证之所以复杂，是因为它需要更安全。

目前很多物联网传感器的接入API，采取了简单身份验证的方式。而大多数可远程操控的智能设备，则采取对称签名机制。

如上图所示，机制云使用的是对称加密的签名机制。

大多数智能设备还不能使用非对称签名，比如ecdsa，为什么呢？因为大部分单片机，不支持非对称加密，而一个支持ecdsa加密算法的安全芯片，会增加很多硬件成本。

最后总结一下，不需要特别注意安全的应用，可以采用简单身份验证配合ip白名单的方式。需要安全的应用，可以使用对称签名身份验证方式。极端需要高安全性的应用，可以采用非对称加密的签名认证方式。

最后，不论采用哪种方式，都尽量能提供好用的sdk，以方便开发者使用。

作者：cr4fun，API产品经理，擅长物联网和区块链。

本文由 @cr4fun 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

「图」微软提议使用新传感器API以改善Chromium的续航表现

通过改善浏览器在调用各种传感器的“兼容性、性能和电池利用率”，微软希望改善Edge和Chrome和其他基于Chromium的浏览器的续航表现。最新消息称微软Edge工程师正致力于在Windows 10平台上为Chromium浏览器提供更好的传感器支持。

根据托管在Google Docs上的文件显示，微软希望Chromium的通用传感器API在Windows 10平台上使用Windows.Devices.Sensors。而目前Chromium所使用的传感器API是ISensor COM APIs，它是基于在Windows 7平台上使用的传感器模型。

微软的三位高级软件工程师表示：“我们建议更新通用传感器API，设备定位和设备运动API的实现，以便在Windows 10上使用Windows.Devices.Sensors。”目前的处理方式基于Windows Portable Devices堆栈来处理传感器，不过在Windows 10系统中微软已经引入了全新的传感器驱动，实现了

● 消除了对Windows Portable Devices（足迹和性能）的依赖

● 简化驱动程序模型的可靠性。

● 通过硬件offload提高性能和电池寿命。

Windows.Devices.Sensors中包含的硬件offload传感器将提供更高的CPU效率，这是现有传感器无法实现的。它还将提高浏览器的性能和可靠性，因为新技术可以更快地对传感器对象进行操作。

微软在commit中写道：“Windows 7.Devices.Sensors在Windows 7上已经不可用。”在Chromium平台上还有相关的一个commit，不过目前的状态是merge-conflict（合并冲突）和work-in-progress（正在处理中）。目前还不知道微软的好主意何时会得到社区的认可，但它应该很快会部署到Edge Canary或Chrome Canary中。

传感器api 如何设计API产品的认证部分？

如何设计API产品的认证部分？

「图」微软提议使用新传感器API以改善Chromium的续航表现

大家都在看

相关推荐