近几年微服务架构逐步成为支流，其中 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 <secret> | base64 std encode

总结

第三方私钥托管就如同一个仓库管理员，当 API 网关想要拜访某一个“仓库”时，只需告诉密钥托管服务，剩下的事件既是期待密钥托管服务为其引路。如何达到这个“仓库”，虽是密钥托管服务的外围性能，却并不是第一要务，保障这条路线的平安才是重中之重。

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