在数字世界中，一个核心挑战是如何确凿地确认信息的真实来源。这篇报道将深入探讨这一议题，作为对先前讨论HTTP API认证与授权技术的补充，聚焦于网络中的身份验证机制。
最直观的身份验证方式莫过于用户密码。当用户提供正确的用户名和密码组合时，我们通常认为其身份得到了确认。这种方法依赖于密码的私密性和唯一性，假设除了用户本人，无人知晓。虽然密码管理、强度设定、泄露防护及破解并非本文侧重，但密码作为第一道防线的重要性不言而喻。
为了进一步提升安全性，双因素认证（2FA）或多因素认证（MFA）应运而生。这要求用户除了密码外，还需提供一个可信设备生成的一次性验证码，如手机短信验证或Google Authenticator等动态口令。结合定期更换密码的习惯，其安全级别能达到较高水准。相较之下，人脸识别等生物识别技术在身份验证领域面临争议，因生物信息（如人脸、指纹）易被获取和伪造，且无法像密码一样被吊销或重置，这限制了其在某些应用中的适用性。
然而，密码验证存在一个根本性缺陷：用户必须向验证方透露密码。这在大规模、多方交互的场景下是不可行的。因此，更先进的解决方案是引入密钥对和数字证书。
利用椭圆曲线密码学（ECC）的非对称加密技术，通过一对密钥（公钥和私钥）进行信息的加密和解密。其中，公钥可广泛公开，而私钥则严格保密。当信息由私钥加密后，任何持有对应公钥的人都可以解密，从而验证信息的发送者身份，这既保护了信息安全，又实现了身份认证。例如，网站通过私钥对自身信息进行加密，并公布公钥，用户即可通过公钥验证网站的真实性，有效防范DNS劫持等中间人攻击。
不过，这种公钥机制依然面临中间人攻击的风险。攻击者可能伪装成合法方，在通信双方之间插入自己的公钥，导致通信方无法辨别公钥的真实归属。为解决此问题，数字证书应运而生。数字证书类似于现实世界的身份证，由一个权威的第三方机构——证书颁发机构（CA）——颁发和验证。
CA机构扮演着受信方角色，运用非对称加密技术来签发和验证证书。其流程大致如下：Alice将其身份信息和公钥打包成证书签名请求（CSR）发送给CA。CA在核实Alice的物理身份后，使用自身的私钥将CSR签署为数字证书。Bob接收到Alice的证书后，利用CA的公钥解密，便能获取到Alice的公钥并确信其真实性，进而验证信息是否确实来自Alice。这种信任链可以延伸，形成由根证书向下延伸的证书链，客户端需验证链中所有CA的签名。
在特定场景下，并非所有实体都需要向大型CA机构申请证书。企业或组织内部可以自行创建“小王国”，生成自签证书。只要确保自签证书私钥的安全及不需跨越互联网信任，这种方式是可行的。例如，使用OpenSSL命令可以演示完整的证书生成过程，包括CA证书和私钥的生成、用户私钥的创建、CSR的生成，以及CA对用户证书的签名。
上述讨论主要围绕单向认证，即确保用户访问到的是真实的服务提供方。但在许多情况下，双向认证的需求也日益增长。例如，微信支付与商户之间的交互就是一个典型场景。当用户完成微信支付后，微信需通知商户支付结果，此时，微信必须确保通知发送给了正确的商户，同时商户也需确认通知来自微信官方，而非伪造。
虽然传统的API认证授权技术，如AppID/AppSecret配合MD5/HMAC签名，能提供一定程度的保障，但云原生应用的首选安全通信协议是双向TLS（mTLS）。传统的TLS认证仅涉及客户端验证服务器证书，而mTLS通过在传统TLS流程中增加客户端出示并由服务器验证其证书的步骤，实现了客户端与服务器的双向身份验证。这意味着mTLS中客户端和服务器都拥有并互验证对方的证书。
mTLS需要“根”TLS证书，它扮演着自建CA的角色，用于签发客户端和服务器所需的证书。尽管mTLS在内部组织、特别是采用零信任安全模型时非常有效，但在公共互联网上全面推广仍面临挑战。因为在公共互联网上，首要任务是确保用户连接到正确的网站并保护数据隐私，而向数十亿最终用户设备分发和管理TLS证书将是一项极其艰巨的任务。然而，在较小的、受控的环境中，mTLS通过对每个用户和设备进行身份验证，极大地增强了网络安全性。用户可参考Golang实现的mTLS示例进行深入了解。