为什么不能把 AI API Key 直接放进移动 App

原生 App 无法保守随包分发的共享秘密

移动应用要在用户设备上自动调用 AI 服务，就必须在某个时刻取得凭据的可用表示。若凭据直接写在源码、资源、构建变量、Native 库或运行时拼接逻辑中，安装包或进程最终都包含恢复它所需的信息。攻击者不需要理解全部业务，只要复制有效请求所需的长期值，就能在应用之外调用接口。工程判断是把任何随所有安装实例共同发布、无需服务端再次授权即可使用的值视为公开标识，而不是秘密。

RFC 8252 OAuth 2.0 for Native Apps 将原生应用视为公共客户端，推荐通过外部 user-agent 和 PKCE 完成授权，而不是依赖客户端秘密。这个边界直接解释了为什么把 AI API Key 放进 App 不成立：同一二进制交付给大量设备，无法证明某次携带共享 Key 的请求来自哪个合法用户、哪次安装或哪个业务授权。Key 一旦泄露，单纯更新客户端不能阻止旧版本继续被提取和重放。

公开客户端并不等于移动端无法安全访问 AI 服务，而是凭据职责要重划。客户端可以持有公开 client_id、一次性授权状态、PKCE verifier、设备生成私钥和短期访问令牌；AI 厂商主密钥、计费账户凭据、模型管理权限和跨租户能力保留在受控服务端。服务端对每次请求重新验证用户、应用版本、授权范围、配额与风险信号，再决定是否代理或签发受限凭据。

隐藏、拆分和 Native 化只改变提取成本

团队常见的补救是把 Key 拆成多段、做字符串加密、放入 so、从多个函数拼接，或在启动后才解密。这些措施可以降低静态搜索直接命中的概率，却没有改变核心事实：应用若能在无人干预时构造有效请求，运行时就必须得到明文或等价认证材料。观察请求构造点、授权头或厂商 SDK 调用，仍可能获得可重放值。

Android Keystore 能限制密钥用途，并在支持的设备上使用硬件保护。它适合保存设备生成私钥、用户解锁绑定密钥或本地数据加密密钥，但不能神奇地保护一份需要预置给所有安装实例的共享 API Key。若应用先从资源解出厂商 Key 再存入 Keystore，首次导入前仍有明文；若 Keystore 中的密钥直接用于生成服务端可接受签名，服务端仍需登记公钥、验证主体和限制权限。

OWASP MASVS-RESILIENCE 把抗逆向和抗篡改放在纵深防御位置。代码混淆、完整性检查和运行时保护可以增加批量分析成本，帮助保护业务逻辑，却不能替代服务端授权和完整发布链。工程判断是继续使用加固降低自动化滥用效率，同时按“客户端秘密终会暴露”设计权限、有效期、撤销和用量限制，避免把全部安全责任压在隐藏字符串上。

正确架构是客户端授权加服务端代理

客户端不应直接持有 AI 厂商的主账户凭据。用户先通过标准登录或设备授权与业务服务建立身份，业务服务根据租户、套餐、模型、地区、应用版本和风险策略判断是否允许请求。允许后，服务端可以代理调用 AI 厂商，也可以签发只面向专用资源服务器的短期访问令牌。厂商 Key 留在秘密管理系统中，只由受限工作负载读取。

代理层不仅隐藏 Key，还把商业和安全边界集中到服务端。它可以限制模型集合、输入大小、并发、调用频率、数据保留、租户隔离和成本预算，并为每个业务主体记录独立用量。客户端即使被修改，也只能发起服务端允许的请求，不能利用主 Key 调用模型管理、文件管理或其他租户资源。具体权限和预算必须来自项目策略，文章不能凭空给出通用阈值。

服务端代理也不是自动安全。若代理接受任意上游 URL、任意模型名或客户端自报租户，攻击面只是从 Key 泄露变成代理滥用。接口应使用明确 schema、服务端映射和资源所有权检查，拒绝自由形式的厂商参数；日志删除授权头和用户敏感输入；错误响应不返回上游凭据、内部端点或完整调试信息。

原生应用授权使用外部浏览器和 PKCE

RFC 8252 建议原生应用通过外部 user-agent 执行 OAuth 授权，让用户在系统浏览器或安全浏览上下文中与授权服务器交互，并使用 PKCE 绑定授权请求和换码。App 生成高熵 verifier，仅在本次授权事务中保存，发送其变换后的 challenge；授权码被其他应用截获时，没有原 verifier 也不能正常换取令牌。

重定向 URI 需要精确注册和验证，应用链接、通用链接或私有 scheme 各有平台边界。RFC 9700 OAuth Security BCP 进一步讨论授权码注入、重定向匹配、令牌重放和不安全 grant。工程判断是弃用资源所有者密码等让客户端直接收集用户凭据的路径，使用 state 或等价事务绑定，授权服务器严格匹配 redirect_uri，并把授权码限定为短期和一次性。

OAuth 登录解决用户授权流程，不直接决定 AI 业务 scope。授权服务器签发前仍要将用户、客户端、租户和允许模型映射为最小权限。原生 App 不能用 client_secret 弥补缺失的业务校验，因为相同 secret 会随安装包传播。任何需要证明“这是某次合法安装”的额外信号，都应在服务端验证，并作为风险信号而不是用户权益本身。

• 使用外部 user-agent 而非嵌入式页面收集账号凭据
• 每次授权生成新的 PKCE verifier 和 state
• 授权服务器严格匹配已登记重定向 URI
• 授权码短期、一次性并与客户端事务绑定
• 不使用安装包内 client_secret 证明客户端身份
• 业务 scope 由服务端账号与租户策略决定

短期令牌要验证受众、权限和主体

RFC 9068 JWT access token profile 说明 JWT access token 可以携带 issuer、audience、expiry、scope 和 client 标识，供资源服务器执行验证。资源服务器不能只检查签名格式，还要确认签发者来自受信配置、audience 包含自身、当前时间在有效期内、scope 覆盖本次动作，并把 subject、client_id 与业务资源所有权结合。

短期不应只写在文档里。授权服务为每类客户端设定最大有效期，资源服务器拒绝超出策略的令牌；高风险操作使用更窄 scope 或一次性授权；撤销、账号冻结和租户状态由服务端实时检查。JWT 自包含可以减少查询，却可能延迟权限变化，因此项目要在有效期、状态查询和缓存之间做明确选择，不能把“格式是 JWT”当成安全结论。

令牌也不应进入 URL、崩溃报告、分析事件或自由文本错误。客户端将 bearer token 放在标准授权头，通过系统安全存储保存必要会话状态，并在退出、撤销或设备风险变化后删除。日志只记录受控的 token 标识摘要、签发者、受众验证结果和错误类别，不记录完整值。没有真实签发与资源服务器配置时，只能说明设计方法，不能宣称令牌策略已经生效。

持有者绑定降低令牌脱离客户端重放

普通 bearer token 谁拿到谁能用。RFC 9449 OAuth DPoP 通过客户端持有的非对称密钥生成每次请求证明，把 access token 与公钥绑定，并在证明中关联 HTTP 方法、目标 URI、时间和唯一标识。资源服务器同时验证 token 绑定与 DPoP proof，可以降低被盗 token 在没有对应私钥时被脱离原客户端重放的风险。

移动端可为每次安装或账号生成独立私钥，并用 Android Keystore 限制签名用途和直接导出。私钥身份需要由授权服务器在合法流程中登记，公钥轮换、应用重装、设备迁移和凭据恢复都有明确状态机。若把同一私钥或私钥材料预置到全部安装包，持有者绑定就退化为另一份共享秘密。

DPoP 不是设备可信证明。被控制的应用进程可能请求 Keystore 为恶意请求签名，服务端仍需验证用户、scope、资源所有权、风险与用量；短有效期和撤销仍然必要。工程判断是把持有者绑定用于缩小 token 被复制到其他环境的重放面，而不是把它描述成能够阻止所有本机滥用。

构建门禁要同时扫描凭据形态和令牌策略

禁止把 Key 放进 App 需要自动门禁，而不是依赖代码评审记忆。流水线可从最终 APK、AAB、IPA、资源、Native 字符串和生成配置中提取公开安全的字符串清单，再检查厂商 Key 前缀、Authorization 样式、私钥头、构建变量名和高熵长值。命中结果只输出文件位置与规则标识，不在普通日志回显完整疑似秘密，避免扫描器本身造成二次泄露。

下面示例读取一份经过脱敏的发布检查 JSON。artifactFindings 只包含规则名和位置，tokenPolicy 则声明允许受众、允许 scope、最大有效期与一次示例令牌声明。脚本在存在任意构建凭据命中、受众错误、权限超集或有效期超过项目策略时失败。它不会读取真实安装包、验证 JWT 签名或处理生产凭据，真实流水线应由专用提取器产生 findings，并在隔离环境验证签发配置。

门禁结果必须绑定最终发布候选摘要。Debug 包未命中不能证明 Release、渠道重打包或后续配置注入也未命中；任何重新构建、重签名或资源替换都需要重跑。允许列表只接受明确的公开 client_id、测试占位符或已撤销样本，并记录负责人和到期时间，不能用大范围正则排除整个配置目录。

• 扫描最终发布候选而不是仅扫描源码
• 覆盖资源、生成配置和 Native 字符串
• 扫描日志不回显完整疑似凭据
• 令牌受众、scope 与有效期都有项目策略
• 允许列表逐项登记负责人和到期时间
• 任何重构建或渠道处理后重新执行门禁

from pathlib import Path
import json
import sys

if len(sys.argv) != 2:
    raise SystemExit("usage: check_credentials.py release-check.json")

source = Path(sys.argv[1])
if not source.is_file():
    raise SystemExit("release check file does not exist")

payload = json.loads(source.read_text(encoding="utf-8"))
findings = payload.get("artifactFindings")
policy = payload.get("tokenPolicy")
claims = payload.get("sampleClaims")

if not isinstance(findings, list) or not isinstance(policy, dict):
    raise SystemExit("artifactFindings and tokenPolicy are required")
if not isinstance(claims, dict):
    raise SystemExit("sampleClaims are required")

failures = []
for finding in findings:
    rule = finding.get("rule")
    location = finding.get("location")
    if not rule or not location:
        failures.append("credential finding lacks rule or location")
    else:
        failures.append(f"credential-shaped value detected by {rule} at {location}")

allowed_audiences = set(policy.get("allowedAudiences", []))
allowed_scopes = set(policy.get("allowedScopes", []))
max_lifetime = policy.get("maxLifetimeSeconds")
audience = claims.get("aud")
scopes = set(claims.get("scope", "").split())
issued_at = claims.get("iat")
expires_at = claims.get("exp")

if audience not in allowed_audiences:
    failures.append(f"token audience is not approved: {audience!r}")
if not scopes or not scopes <= allowed_scopes:
    failures.append("token scope is empty or exceeds the approved set")
if not all(isinstance(value, int) for value in (issued_at, expires_at, max_lifetime)):
    failures.append("token lifetime fields must be integers")
elif expires_at <= issued_at or expires_at - issued_at > max_lifetime:
    failures.append("token lifetime exceeds the release policy")

if failures:
    print("credential release gate failed:")
    for failure in failures:
        print(f"- {failure}")
    raise SystemExit(2)

print("artifact and short-lived token policy checks passed")

发现已发布 Key 后先撤销再修版本

如果长期 Key 已进入发布包，应按已泄露处理，而不是先提交一个删除字符串的新版本。首要动作是在厂商或秘密管理侧撤销、轮换并限制旧 Key，检查异常用量、模型调用、文件操作和账单影响；然后临时收紧服务端配额与允许模型。客户端商店更新无法覆盖所有已安装版本，也不能让公开仓库、缓存和第三方镜像中的旧包消失。

修复架构时把厂商 Key 移到服务端代理，引入用户授权、短期令牌、最小 scope、资源所有权检查和独立用量归属。旧客户端如果仍直接调用厂商 API，应在服务端或厂商侧逐步拒绝旧凭据，并设计可理解的升级提示，不能为了兼容永久保留已泄露 Key。调查记录保存候选摘要、Key 身份、撤销时间、观察窗口和确认边界，不保存完整 Key。

最终结论要限定证据范围，例如指定 Release 候选未命中已知凭据规则、服务端签发策略满足列出的受众与 scope 检查，而不是“密钥永远无法提取”。准备评估时，可通过御盾中央平台提交脱敏后的架构图、最终候选、凭据清单、令牌策略和资源服务器验证规则，先固定检查对象与授权边界。

• 已发布凭据立即撤销或限制而非等待发版
• 检查厂商用量、账单和高风险操作
• 修复版本不继续兼容已泄露主 Key
• 旧客户端迁移具有明确截止和拒绝策略
• 调查材料不复制完整秘密
• 最终结论绑定具体候选与服务端配置