启用 OAuth2 插件
覆盖 218 个 route、168 个 service
结论先行
现在不是细 Scope，而是 all + 未配置
Kong 负责 token 与 scope，但资源访问阶段没有按 route 所需 scope 做授权判断。现有历史关系只能从 APILog 恢复“实际用过什么”，不能恢复“原本打算允许什么”。
39,324,517 条 gateway-inner OAuth2 日志，scope 100% 为 all
ACCESS TOKENscope = allglobal_credentials = true
ROUTE APASS
ROUTE BPASS
ROUTE CPASS
ROUTE DPASS
四个数字看清现状
数据来自 gateway-inner 当前 Kong Admin API、线上 kara-oauth2-v2 部署，以及 ES 中 label=kong_inner 的 90 天 APILog。
OAuth2 Credential
隶属 152 个 consumer
90 天活跃 Route
另有 64 个当前 route 无调用
实际调用关系
credential × route 去重结果
当前明确登记过的 scope 只有 all；不存在一批隐藏的细粒度 scope 等待导出。
Kong 里实际配置了什么
219 个 OAuth2 插件中 218 个启用。scopes 字段主要是 null，而不是业务权限定义。
Scope 配置分布
213 null4 [all]1 []
全部 global_credentials=true
OAuth2 credential 不受原签发 service 限制。结合资源访问阶段没有 scope guard，scope=all 在实践中就是跨 OAuth2 route 的广泛权限。
查看 4 个显式 scopes=[all] 的 Route
| ROUTE | PATH | MANDATORY |
|---|---|---|
ai.rp.oauth2.v1.0.0 | /api/v1.0.0/rp | 否 |
gateway.bin | /gateway/bin | 是 |
pto.fap.ai.com.oauth2.all.v1.0.0 | /api/v1.0.0/fap/pto | 是 |
ai.rp.common.oauth2.v1.0.0 | /api/v1.0.0/rp/common | 否 |
唯一 scopes=[] 的配置位于 ai.train.authorized_by_oauth2。它同样不是资源 required-scope 规则。
缺的是最后一跳
Kong 原生 OAuth2 插件会验证 token、有效期和 credential，并把 token.scope 写入 X-Authenticated-Scope；它不会判断当前 route 要求哪个 scope。
接收并透传 Scope
scope=all密码与 exchange 默认 all，device flow 固定 all。
签发与验证 Token
granted=allgateway.bin 当前只允许签发 all。
资源 Scope 授权
required=?没有统一的 route + method scope enforcement。
历史关系：潜在权限与实际使用必须分开
当前配置允许的范围很大；APILog 证明的真实使用范围很小。收口不能直接继承全部潜在组合，也不能无观察期地只保留日志命中。
潜在 credential-route 组合
241 credential × 218 OAuth2 route。它代表当前可能访问的上限，不代表业务授权意图。
实际 credential-route 组合
39,324,517 条 OAuth2 请求聚合所得；另有 628 个 credential-service 组合。
活跃 credential 每个使用 route 的中位数为 2，P90 为 13，最大为 64；102 个当前 credential 在日志保留期内没有调用。
14只读 Route
22只写 Route
118读写混合 Route
11含 PUT/PATCH/DELETE
IdP 与网关能力判断
线上 kara-oauth2-v2 镜像为 2026.07.27.17.43；它会直接读取 Kong OAuth2 credential 与 redirect_uri，但没有 client → allowed scopes 授权表。
IdP 当前行为
- 授权码、隐式、密码、exchange 的 scope 基本透传给 Kong
- 密码与 exchange 默认 all；device client 固定 all
- OIDC Discovery 声明 openid/profile/email，但 gateway-inner 实际只签发 all
Kong 可实施能力
- 插件清单可见 OPA，但官方 OPA 插件属于 Enterprise 能力，当前未配置且界面不可直接启用
- 当前只有 1 个 pre-function 实例，不存在普遍 scope guard
- 无 Enterprise 许可证时，更适合新增统一的轻量 scope-policy 插件与本地策略缓存
兼容收口：all 不再是通配符
旧客户端仍可以暂时请求 all，但网关要把它解释成“该 credential 的兼容权限集合”，而不是全部 route。
生成兼容基线
用 666 条观察关系建立 credential + route + method 清单；102 个无调用 credential、64 个无调用 route 单独确认。
Shadow 校验
新策略先只记录 would-deny，不阻断。补齐低频调用和负责人确认，冻结兼容授权集。
双轨迁移
新 client 禁用 all；老 client 的 all 只命中兼容集。迁移完成后由 IdP 改发具体 scope。
建议的职责边界
IdP 限制“client 能申请哪些 scope”；网关限制“scope 能访问哪些 route + method”；Kong OAuth2 插件继续负责 token 签发和身份校验。
Token 生命周期对迁移的影响
access token 有效期 2 小时；refresh token 有效期 14 天，reuse_refresh_token=false。仅停止新签发 all 不足以收口，因为 refresh 链可能继续保留 all。网关策略必须能约束既有 token，最终切换还要处理 refresh token 的迁移或撤销。
证据与边界
本报告只使用聚合字段，没有导出 authorization、apikey、refresh token、client_secret 或 request.body。
gateway-inner Kong Admin APIOpenShift 实时 Deploymentkong-log-* / label=kong_inner2026-05-29 至 2026-08-26kara-oauth2 commit 2d8c979只读，无配置变更
重要的数据安全发现
全局 tcp-log 会写入 request.body，ES mapping 还包含 authorization、apikey、refresh token、client_secret 等字段。后续盘点应继续只导出聚合结果和字段白名单，不应分发原始 APILog。