📚 课程目录第3章 AI应用认证机制工程

3. AI应用认证机制工程

AI应用的身份认证与普通Web应用有一个关键差异：调用链往往由“人—应用—模型服务—工具/数据源”多段组成，既有用户身份，也有工作负载身份。把API密钥、OAuth 2.0、OIDC、JWT、mTLS混用或误用，是AI系统最常见的权限事故来源。本节先厘清五种机制在AI调用链中的位置，再给出选型、配置与风险控制方法。

一、五种机制的本质区别

API密钥是一段长期有效的共享秘密，服务端只校验“密钥是否正确”，不携带调用者身份语义。它适合服务端到服务端的低敏感调用，但一旦泄露即等同于身份被冒用，且难以细粒度撤销。

OAuth 2.0是授权框架，解决“应用如何获得访问资源的权限”，核心产物是access token。它不规定用户身份如何表达，只规定授权流程（如授权码、客户端凭证）。在AI场景中，常用于让AI应用代表用户访问第三方数据源。

OIDC构建在OAuth 2.0之上，增加身份层，核心产物是ID Token（一个JWT），用于回答“用户是谁”。AI应用需要确认“当前对话属于哪个用户”时，应使用OIDC而非裸OAuth。

JWT是一种令牌格式，不是认证协议。它可以承载OIDC的ID Token，也可以承载OAuth的access token。JWT的价值在于自包含声明（iss、sub、aud、exp、scope），风险在于签名校验缺失、算法混淆（alg=none或HS/RS混用）和过期时间过长。

mTLS是双向TLS，客户端与服务端互相验证证书，提供强工作负载身份。它适合模型服务网格内部、Agent与工具服务之间的调用，能防止未授权工作负载接入，但不表达用户级权限。

二、选型判断：按调用段选择机制

选型不应按“哪个更安全”排序，而应按调用段身份类型决定。下面给出一个可直接套用的判断表（示例参数，非实测）：

调用段	身份主体	推荐机制	关键校验
用户 → AI应用	自然人	OIDC + JWT	iss、aud、exp、nonce、签名算法
AI应用 → 模型服务	工作负载	mTLS	证书链、SPIFFE ID、吊销状态
AI应用 → 内部工具	工作负载	mTLS 或短期JWT	aud 限定、scope 最小化
AI应用 → 第三方SaaS	用户授权	OAuth 2.0 授权码 + PKCE	state、code_verifier、scope
批处理 → 内部API	服务	API Key（受限）	IP白名单、速率限制、轮换

三、配置要点与可执行示例

以OIDC + JWT校验为例，AI应用在收到ID Token后必须完成以下校验，缺一不可。下面是一段Node.js风格的校验逻辑示例（示例参数，非实测）：

// 示例：OIDC ID Token 校验关键步骤
const jwksClient = require('jwks-rsa');
const jwt = require('jsonwebtoken');

const client = jwksClient({ jwksUri: 'https://idp.example.com/.well-known/jwks.json' });

function getKey(header, callback) {
  client.getSigningKey(header.kid, (err, key) => {
    callback(null, key.getPublicKey());
  });
}

jwt.verify(idToken, getKey, {
  algorithms: ['RS256'],          // 显式限定算法，防 alg 混淆
  audience: 'ai-app-client-id',   // 必须匹配本应用
  issuer: 'https://idp.example.com/',
  clockTolerance: 5               // 允许5秒时钟偏差
}, (err, decoded) => {
  if (err) throw new Error('token invalid: ' + err.message);
  // decoded.sub 即用户唯一标识，用于后续权限映射
});

mTLS配置的核心是证书签发与轮换。在服务网格中，通常由控制面为每个工作负载签发短周期证书（如24小时），SPIFFE ID形如 spiffe://cluster.local/ns/ai/sa/model-client。服务端校验时不仅要验证证书链，还要校验SPIFFE ID是否在允许列表内，避免“有证书即可访问”的误区。

常见配置错误：把API Key写进前端JavaScript或移动端包体；JWT校验时只解码不验签；OAuth回调未校验state导致CSRF；mTLS只验证书不验身份。这四类错误在AI应用中占比最高，应作为上线前必查项。

四、风险控制与凭证生命周期

认证机制的风险控制要覆盖“签发—使用—轮换—撤销”全周期。API Key应设置90天轮换、支持即时撤销、绑定IP或来源；OAuth token应使用短期access token（如1小时）配合refresh token，refresh token需绑定客户端并支持撤销；JWT应控制exp在5～15分钟，避免长期有效；mTLS证书应短周期自动轮换，并维护吊销列表。

工程建议：在AI网关层统一做认证收敛——外部请求统一走OIDC/OAuth，内部服务间统一走mTLS，API Key仅作为过渡或低敏感场景使用。这样可以把“认证逻辑”从每个AI应用中抽离，降低配置漂移风险。

最后需要强调：认证只解决“你是谁”，授权才解决“你能做什么”。在AI应用中，用户身份（OIDC sub）与工作负载身份（mTLS SPIFFE ID）应分别映射到权限模型，避免用同一个凭证同时表达两种身份。只有把认证机制与调用段、身份类型、生命周期管理对齐，AI服务的身份权限安全才具备可工程化的基础。