我正在使用 Azure 的 KEY Vault 来存储加密密钥并处理加密和解密，因为我们有一个要求保留加密密钥的规范offsite，但这给我留下了如何处理access_token从 azureOauth进程收到的问题。
常识告诉我，当存储在数据库中时我应该加密这个令牌，但是我不能这样做，因为 azure 上的加密功能需要令牌执行加密和解密，因此不能用于加密自身。
看来我所做的只是移动球门柱，我不再将加密密钥存储在数据库中，而是有一个访问令牌，无论如何都可以用来解密数据。出于同样的原因，我必须存储client_id和未加密。client_secret
我在这里错过了什么吗？
我不确定access_token您从 Azure 身份验证收到的是否具有永久生命周期。我假设不是。无论哪种方式，您仍然需要拥有client_id并client_secret获得access_token，这意味着您应该专注于保护client_secret或寻找替代方案。
client_secret您可以按照本文档中的说明使用客户端证书身份验证，而不是使用进行身份验证：使用证书而不是客户端密钥进行身份验证。
在上图中，开发人员无需知道证书的私钥值即可成功通过 Azure Active Directory 的身份验证。相反，他们只需要知道pfx证书存储中导入的位置。
至少在 Windows 上，您作为机密管理员可以将私钥和证书转换为受密码pfx保护的格式，然后将其部署到 Windows 证书存储中。这样，除非他们知道文件的密码，否则没有人可以知道私钥。pfx
Azure Compute 的另一种方法细节是使用Azure Managed Service Identity。使用 Azure MSI，Azure 将自动为您的资源（例如 VM）分配一个标识/服务主体，并且您可以在特定端点上触发请求，这些请求只能由您的资源访问以获取access_token. 但请注意 Azure MSI 仍处于公共预览阶段，因此请在使用前查看已知问题。
上图说明了 Azure 资源管理器如何将服务主体标识分配给您的 VM。
access_token服务主体的。access_token访问授权服务主体访问的资源，例如 Key Vault。