凭据管理

获取第一个令牌只是开始。一旦 OAuth 应用程序投入使用，其凭据就需要被安全地存储、偶尔轮换，并在出现问题时能够迅速吊销。这些正是安全审查会提出的问题。本页将介绍这三个方面，以及泄露的令牌实际能触及的范围，还有一旦发生泄露该怎么做。

客户端密钥应该放在哪里

将其存储在环境变量或密钥管理器（AWS Secrets Manager、Vault 等）中，绝不放入版本控制，也绝不放入与代码一起提交的配置文件中。
绝不要把它内置到桌面应用程序或基于浏览器的客户端中。任何安装在用户机器上或提供给浏览器的东西，其二进制文件或打包内容都可能被检查，因此其中嵌入的任何密钥从发布的那一刻起就必须被视为公开的。
这正是为什么 Native Application 流程根本不发放客户端密钥：它专为无法保密密钥的桌面和 CLI 集成而设计，因此转而依赖 PKCE（一种与授权码绑定的按请求证明）。Authorization Code + 自定义 HTTPS 重定向流程也使用 PKCE，并且仅允许其重定向处理程序运行在你自己掌控的服务器上的机密客户端添加客户端密钥。如果该流程完全在浏览器中实现（SPA），出于与 Native 流程从不使用密钥相同的原因，也不应设置密钥。参见入门指南：选择 OAuth 流程。
Client Credentials 是服务器到服务器的流程，始终需要密钥：请按照与其他任何服务器端凭据相同的规则存储它。

在应用程序的 Settings → OAuth 中重新生成密钥会将其彻底替换。不存在新旧密钥同时有效的窗口期：仍在使用旧密钥的调用方，会在下一次令牌或刷新请求时被拒绝。

但这并不意味着一轮换密钥，所有正在进行的请求就会立即失败。已经签发的访问令牌会一直有效，直到其自身的 TTL 到期（约一小时，参见令牌生命周期），无论最初签发它的密钥后来发生了什么变化。只有新的令牌请求或刷新才需要新密钥。

推荐的切换顺序：

如果你无法原子化地更新每个实例，请将轮换规划为一次协调一致的部署，而不是逐步推出：仍持有旧密钥的实例会在下一次需要令牌时彻底失败，而不会优雅地回退到旧密钥。

有两种方式可以切断访问，两者都会阻止新的访问：

在 Settings → Third-party access 中撤销单个授权。该应用程序将无法再通过该授权刷新或获取令牌，其他用户对该应用程序的使用不受影响。
在 Settings → OAuth 中删除 OAuth 应用程序。这会对所有人吊销它：无法再为其签发新的访问令牌或刷新令牌，其客户端密钥也会像轮换后一样失效。对于使用客户端凭据的应用程序，同一操作还会停用该应用程序的服务用户。

撤销授权、删除应用程序和轮换其密钥都不会影响已签发的访问令牌，也不会强制其过期。请将该令牌视为在其自身 TTL 到期前仍可使用，且保留原有的作用域。有关什么会以及不会影响一个有效令牌的完整说明，请参见令牌生命周期。

泄露的令牌并不意味着整个组织的泄露：按照三层安全模型，它受到双重限制：

其 OAuth 作用域（第 1 层）：在签发时就固定在令牌中。之后从应用程序中移除某个作用域，并不会缩小已签发令牌的权限范围；这只有在令牌下一次被刷新或重新签发时才会生效。
服务用户的内容访问权限和角色（第 2 层和第 3 层）：即该令牌的服务用户可以看到哪些节点（组织、部门、站点），以及可以在那里做什么。与作用域不同，这不是固定在令牌中的：它会在每次请求时根据你当前的配置进行评估。

实际的结论是：你从一开始就把应用程序及其服务用户的权限限制得越紧，泄露的令牌价值就越低。

按以下顺序处理：

立即轮换客户端密钥（Settings → OAuth → 你的应用程序）。这是你能采取的最快措施，会立即阻止任何使用旧密钥的新令牌或刷新请求成功。
如果你不打算继续使用该应用程序，或怀疑泄露范围超出了单个密钥，删除该 OAuth 应用程序。对于客户端凭据应用程序，这也会停用其服务用户，彻底切断新令牌的签发。
收紧或移除该服务用户的内容访问权限。 由于内容和角色访问权限（第 2-3 层）是实时校验的，而不是固定在令牌中的，这样做能立即缩小一个仍然有效的泄露令牌所能触及的范围，即便在其 TTL 到期之前也是如此。
将该令牌再视为有效一个 TTL 窗口（约一小时）。以上任何一步都不会强制使已签发的令牌过期。
签发新的凭据（新的密钥，或新的应用程序）并在恢复正常使用之前更新你的集成。