OAuth还是API Key：访问用户数据时如何选择

选择OAuth还是API Key，先看调用是否代表用户访问私人资源。公开数据和低风险机器调用可以考虑受限的API Key；涉及敏感或高价值用户资源时，不应只靠一把Key。OWASP的REST安全建议明确提出，不应仅依赖API Key保护这类资源。

两者的核心区别是凭据代表谁、能访问什么，以及泄露后能撤销到什么范围。API Key通常识别项目或调用方；OAuth可以让应用取得代表用户的授权，也可以让符合条件的服务以自身身份取得访问令牌。OAuth授权框架定义了这些参与方和授权方式，因此“机器用Key、用户用OAuth”只能作为起点，不能代替选型。

先分清调用方身份与资源授权

API Key一般随请求提交，用于让平台识别调用它的项目、应用或合作方。平台可以给Key附加接口、来源、配额或到期限制，但这些能力取决于具体实现。若多人共用一把Key，单凭这把凭据无法区分每位用户同意了哪些操作，也难以只停止其中一人的访问。

代表用户访问时，OAuth把应用的身份、用户授予的权限和访问资源所用的令牌分开。用户可以授权特定范围，授权服务器据此签发令牌；资源服务器仍需判断该令牌是否适用于当前资源和操作。客户端向授权服务器证明自身身份所用的秘密，与提交给资源服务器的访问令牌，承担不同任务，不能混为一谈。

固定Key并非必然没有权限控制，OAuth令牌也并非必然短期有效。真正影响风险的是实际配置：凭据能否限制到必要操作，是否跨环境或客户共用，泄露后需要停用多少正常连接。若业务要求每位用户或每家合作方分别授权和撤销，共用长期Key会把这些边界绑在一起。

四种场景怎样选择

公开数据：Google的API凭据说明把公开日历列为可用API Key访问的数据例子，前提是数据所有者已将其公开。若接口允许Key调用、应用不需要代替用户读取账户内容，受限Key通常是较简单的选择。公开可读仍可能产生调用成本，应按平台提供的能力限制可调用接口、来源和用量。
服务间调用：受控服务以自身身份访问权限固定、风险较低的接口时，可以给不同服务分别发放Key，并设置必要的限制与轮换机制。若需要短有效期、按资源划分权限或按服务独立撤销，OAuth客户端凭据流程更合适。该流程依据服务自身的权限安排，并不表示某位用户临时作出了授权。
代表用户访问：应用读取或修改个人日历等私人资源时，应取得用户对所需操作的授权，再使用相应令牌请求资源。项目级Key即使能识别应用，也不能凭自身表明某位用户允许访问哪份记录。资源服务器还必须核对请求针对的用户、资源和操作，不能只因令牌有效就放行。
第三方集成：外部应用持续访问客户数据时，宜让客户清楚授予哪些权限，并能撤销该集成的连接。若现有接口只提供长期Key，应核实能否按客户或合作方分配独立凭据、收窄权限并及时轮换。资源越敏感，共用Key被撤销时牵连的正常连接越值得提前考虑。

有效期、权限范围和撤销粒度如何影响选择

先确定凭据的主体：是整个项目、一项服务、某家合作方，还是一位用户对某个应用的授权。随后看它能访问公开内容、读取私人数据，还是修改高价值资源。同样叫作“API Key”的凭据，实际权限可能相差很大；仅凭名称无法判断它是否安全。

长期有效的Key若同时用于生产与测试环境，一处泄露可能迫使多处配置一起更换。按环境和调用方分配凭据，能够缩小停用单把Key的影响，但前提是平台允许独立签发和撤销。对于权限稳定、风险较低且能独立轮换的机器调用，管理得当的Key仍有用武之地。

OAuth可以签发限定范围和有效期的访问令牌，但这些边界必须由授权服务器设置，并由资源服务器执行。需要长期连接时，刷新令牌可用于申请新的访问令牌；它也因此是需要妥善保存和撤销的高价值凭据。选型时应同时确认令牌到期后怎样续期、用户撤销授权后现有令牌怎样失效，而不是只看初次授权是否方便。

OAuth为什么仍可能配置出风险

采用OAuth并不会自动防止授权码被截获、令牌误发或越权访问。RFC 9700安全最佳实践要求公共客户端在授权码流程中使用PKCE，建议机密客户端也使用，并建议在可行时采用mTLS或Private Key JWT等非对称客户端认证方式。PKCE保护授权码兑换环节，不能代替资源服务器对权限范围和目标资源的检查。

授权服务器需要严格匹配已注册的重定向地址，防止授权码或令牌被送往错误位置。资源服务器则应检查令牌的有效性、目标资源和操作权限；仅验证令牌签名不足以决定某条用户记录能否被读取。若签发刷新令牌，还需要考虑轮换或发送方约束，否则长期凭据一旦泄露，可能持续被用于申请新令牌。

因此，OAuth的实施工作包括授权回调、令牌保管、续期、撤销和资源端校验。对只读公开数据接口，这些环节可能增加不必要的复杂度；对需要个人授权与精细撤销的接口，它们支撑着访问边界。安全收益来自正确配置和持续执行这些边界，而不是协议名称本身。

凭据泄露后怎样撤销

先辨认暴露的是API Key、OAuth客户端秘密、访问令牌还是刷新令牌，并确定对应的应用、环境、权限及可能受影响的用户。仅从代码仓库删除字符串，无法让已经复制的凭据失效；应同时查清它可能出现在哪些日志、配置或部署中。
如果是API Key，按平台机制停用或轮换受影响的Key，向合法调用方分发新凭据，再核查暴露期间的访问记录和用量。多项服务共用同一把Key时，需要协调替换，避免误停正常业务。后续按调用方分配凭据，可以缩小再次撤销时的波及范围。
如果是OAuth令牌，通过授权服务器支持的机制撤销受影响的令牌或授权，并确认相关访问令牌何时失效。RFC 7009令牌撤销规范说明，撤销刷新令牌对相关访问令牌的影响取决于服务器支持与策略，分布式系统中还可能存在撤销状态的传播延迟。因此，不能仅凭撤销请求成功就推定所有资源服务器已同时拒绝旧令牌。
如果泄露的是可用于申请新令牌的客户端秘密，还需轮换该秘密，并核查它所关联的授权。恢复连接前，应确认旧凭据已被拒绝，再为必要调用授予合适的权限。处置范围应对应实际暴露的凭据和权限，避免为了切断一个连接而无差别停用其他用户的访问。