API 认证与授权：机制、权衡与失效模式的工程深度解析
内容提要
本文系统讲解七种API认证机制：Basic Auth、API密钥、Bearer Token、JWT、OAuth 2.0、OIDC和mTLS，分析其原理、代码实现、失效模式及适用场景。作者强调TLS、密钥轮换、域名白名单、密钥管理和日志脱敏等组织规范，指出多数漏洞源于开发者不了解失效模式，而非能力不足。
延伸解读
认证与授权：不可混淆的两道防线
文章开篇强调，认证解决“你是谁”，授权解决“你能做什么”，二者必须独立正确。一个认证完美但授权糟糕的系统仍会泄露数据；一个授权完美但认证薄弱的系统可被轻易绕过。许多真实漏洞源于将两者混为一谈，或只关注其一。工程上，应在架构中明确分离认证与授权逻辑，分别测试和加固，避免因一方缺陷导致整体安全失效。
TLS 是底线，而非可选项
文章指出，所有 API 通信必须使用 HTTPS，且所有端点与环境无一例外。Basic Auth、API 密钥、Bearer Token、JWT 均在 HTTP 头中明文传输，无 TLS 即可被截获。基础设施必须强制 TLS 1.2 及以上，拒绝旧协议。这是配置决策，不应在代码中处理。开发测试环境也需独立凭证，禁止将生产数据复制到非生产环境，否则可能违反 NDPA 2023 或 PCI-DSS。
JWT 的失效模式：实现错误而非标准缺陷
文章列举 JWT 常见致命错误：算法混淆攻击（接受 none 算法）、弱签名密钥可被离线暴力破解、无过期时间、载荷存放敏感数据、缺乏撤销策略。这些均为实现失误。正确做法包括：强制校验算法、使用至少 256 位强密钥或非对称算法、设置短过期时间（15 分钟至 1 小时）、仅存放标识符、维护令牌黑名单或使用刷新令牌轮换。JWT 适合无状态大规模 API，但需权衡撤销复杂度。
组织纪律：技术之外的安全支柱
文章强调，技术实现只完成一半，另一半是组织规范。包括：API 密钥轮换必须计划性主动进行，而非泄露后补救；密钥不得跨客户端或环境复用；机密信息必须从可信密钥管理器运行时获取，禁止硬编码或提交至仓库；加密算法应由架构师统一规定，并提供内部共享包，避免开发者自行实现；日志需在框架层强制字段脱敏，确保授权头、令牌、密码等永不记录。这些标准需在流水线中强制执行。
Q&A
API认证和授权有什么区别？
认证回答“你是谁”，授权回答“你被允许做什么”。两者必须独立正确：认证完美但授权差会泄露未授权数据，授权完美但认证弱则容易被绕过。
Basic Auth 在生产环境中的主要风险是什么？
凭证在每个请求中传输，一旦被截获，攻击者永久获得用户名和密码。Base64只是编码不是加密，没有过期和撤销机制（除非改密码）。若没有速率限制，还容易遭受暴力破解。
JWT 有哪些常见的实现错误会导致安全漏洞？
常见错误包括：算法混淆攻击（如接受none算法）、弱签名密钥可被离线暴力破解、没有设置过期时间、在payload中存放敏感数据（Base64可解码）、缺乏撤销策略。这些是实施错误而非标准缺陷。
OAuth 2.0 和 OpenID Connect 有什么区别？
OAuth 2.0 是授权框架，用于让第三方应用在不共享密码的情况下访问用户资源；OpenID Connect 在 OAuth 2.0 之上增加了认证层，通过ID Token提供用户身份信息（如邮箱、姓名）。简单说：OAuth管授权，OIDC管认证。
mTLS 适用于哪些场景？它的主要运维挑战是什么？
mTLS 适用于高安全服务间通信（如支付网关、银行API）和受监管环境中的微服务。主要挑战是证书管理：证书会过期，若未自动化轮换会导致服务中断；CA基础设施必须安全，否则所有签发的证书都受威胁。
如何根据应用场景选择API认证机制？
面向用户的应用：JWT bearer token（短时效+刷新令牌轮换）；第三方委托访问：OAuth 2.0，需验证身份时加OIDC；企业SSO：OIDC；服务器间低安全需求：API密钥（域名白名单、环境隔离、定期轮换）；受监管高安全服务间：mTLS；内部工具：Basic Auth（仅当TLS保证）。选择应基于调用者、数据敏感度和合规要求。
组织在API密钥管理上应遵循哪些纪律？
密钥轮换必须定期主动进行，而非泄露后补救；每个密钥只能用于单一客户端和环境，禁止跨环境复用；密钥绝不能硬编码在源码或提交到仓库，必须运行时从密钥管理器获取；加密算法应由组织统一标准，并提供内部共享加密包；日志必须字段级脱敏，防止敏感信息泄露。
