微服务身份认证需求下的私钥托管痛点与破局

近几年微服务架构逐渐成为主流，其中 API 网关的价值不言而喻。在 API 网关中，API 代理及编排则是重要的组成部分。一般来说支持对外提供 API 服务的系统，都会引入身份认证功能，以此保证 API 不会被恶意调用。因此要想实现 API 代理，必须先完成身份认证。

由此，能够为密钥提供托管及认证服务的密钥管理模块便成为了合适的解决方案。而对于需要调用各式各样外部 API 的系统来说，怎样去兼容形形色色的认证方式就成为了一个重点。本文将着重介绍在第三方私钥托管中，存在的痛点以及如何解决。

第三方私钥托管

那么何为第三方私钥托管？对于提供开放 API 的系统，为避免恶意访问，常需要先进行请求鉴别。一般来说对外开放的系统会提供相关 API 访问时的密钥，只有当用户使用密钥经过特定的方式访问时，系统才会对该请求作出相应的应答。

第三方私钥托管用于管理用户所需要的外部系统的密钥信息，并提供透明化的鉴权方式。正如一个管家一样，只需要在首次创建时告诉管家相关的信息，在后续的使用过程中，一切操作全由管家处理。

痛点与破局

密钥权限问题

密钥是用户访问外部系统的唯一凭证，对用户数据安全有着至关重要的作用。所以，用户是不会轻易将此数据泄露给任何不可信的第三方的。而需要代理用户向外部第三方系统发送访问请求，又必须由用户提供密钥信息。

因此，需要设计一套严密的安全体系，让用户信任我们的系统。为此，在密钥管理上必须采取相关措施：密钥加密上传，加密存储等。除此之外，为确保密钥不被泄露，上传之后的密钥信息对任何人是不可见的，且在使用过程中也是透明化，最大程度保证用户密钥的安全性。

身份认证方式的差异性

面对不同的系统，鉴权认证的方式也各不相同。例如常见的身份认证方法有：OAuth2、JWT、Signature 等。针对不同的认证方法，做到统一其调用过程，对外屏蔽鉴权实现，往往也是值得关注的。

将鉴权方式统一来看，无外乎都是通过特定的方式换取用户请求资源时所需携带的令牌（Token），以 JWT 为例，用户输入密钥（如：用户名及密码）之后，服务端检查合法性之后返回 JWT，随后的所有访问中将携带该信息。通过这种方式，对于外部调用时，只需要关注获得 Token，至于这个 Token 是以何种方式得到的根本不需要关心。

Signature 方法变化万千

Signature 认证只是对“签名”的一种统称。至于采用什么样的算法，以及以何种方式去做计算，是没有固定的。从简单的将参数进行排序后计算哈希值，到复杂的如反复进行加密运算并做 base64 等编码之后才得到签名字符串。而如何提供 Signature 方法，满足各式各样的签名需求成为了一个难题。

分析常用的 Signature 不难发现，一般复杂的签名算法都是各种基础算法的组合，例如常见的“签名”方法：参数排序、计算 HASH、AES/RSA 加密解密、hex/base64/url 编码解码等。想要得到一个完整的所需要的算法，只需要将这些方法通过特定的方式进行组装，而这些方法本身是标准化的。

解决了如何拆分 Signature 的问题，现在只需要提供一种方法将这些“签名”方法组装起来。类比 Linux 中的 Shell 命令，这些方法便如同一个个指令，而在 Shell 中能够以“|”将命令以管道的方式组合起来，形成一个可以实现复杂操作的命令集。此时将方法看作命令，最后再以管道的方式将其串行组装，形成用户自己所需要的 Signature。

例如：需要将所传递的参数进行降序排序，然后通过密钥进行 rsa 加密，最后再通过 base64 编码，该签名命令则可以通过下面的方式实现。

sort desc | rsa encode  | base64 std encode

总结

第三方私钥托管就如同一个仓库管理员，当 API 网关想要访问某一个“仓库”时，只需通知密钥托管服务，剩下的事情既是等待密钥托管服务为其引路。如何到达这个“仓库”，虽是密钥托管服务的核心功能，却并不是第一要务，保证这条道路的安全才是重中之重。

公众号：全象云低代码
GitHub：https://github.com/quanxiang-...