一、引言：AI 扩展的“身份之困”

2026年，浏览器扩展生态正经历一场深刻的变革。根据Google官方信息，Manifest V3（MV3）的迁移已进入最后阶段，Manifest V2已基本退出历史舞台。与此同时，AI驱动的Chrome扩展如雨后春笋般涌现——从智能邮件助手到代码辅助工具，从内容总结插件到自动化工作流引擎——这些扩展无一例外需要访问用户的第三方服务：Google Drive、GitHub、Notion、Slack、Twitter/X等。

但问题来了：如何让一个运行在浏览器中的AI扩展，安全地获取用户授权，访问其第三方服务数据？

OAuth 2.0作为现代身份授权的事实标准，本应是答案。然而，Chrome扩展的特殊运行环境——客户端代码完全暴露、无后端服务器、受限于浏览器沙箱——让OAuth 2.0的集成变得异常棘手。更严峻的是，2026年4月，安全研究公司Socket发现Chrome Web Store中存在超过100个恶意扩展，其中54个通过chrome.identity.getAuthToken API窃取Google OAuth2 Bearer令牌，影响超过20,000名企业用户。

这不是孤立事件。2026年6月24日，Google修复了CVE-2026-13029，一个位于Chrome Web Authentication API中的高危Use-After-Free漏洞，攻击者可利用恶意扩展触发堆破坏并执行任意代码。

本文将从架构设计、安全风险、部署方案、生态工具和竞品对比五个维度，系统性地探讨Chrome扩展OAuth 2.0集成的正确姿势。 无论你正在构建AI驱动的Chrome扩展，还是迁移现有MV2扩展到MV3，这篇文章都将为你提供可落地的技术方案。

二、背景：Manifest V3 时代的 OAuth 集成新范式

2.1 Manifest V3：不仅仅是版本号的变化

自2022年1月17日正式终结对Manifest V2的审核支持以来，Google推动的MV3迁移已成为全球数百万浏览器扩展开发者必须直面的技术升级。

MV3带来的核心变化直接影响OAuth集成方式：

维度 Manifest V2 Manifest V3
后台脚本 持久化Background Page 事件驱动Service Worker（无DOM，不持久化状态）
远程代码 允许 严格禁止，必须打包所有代码
网络拦截 webRequest（阻塞式） declarativeNetRequest（声明式）
权限模型 宽松 更严格的权限声明

对于OAuth集成而言，最大的挑战来自Service Worker的无状态特性。在MV2中，你可以将OAuth令牌保存在Background Page的内存中，跨请求复用。但在MV3中，Service Worker会频繁休眠和唤醒，内存状态不可靠——必须将令牌持久化到chrome.storage中。

根据2026年5月的一份迁移报告，开发者在迁移17个Chrome扩展时遇到的常见陷阱之一，就是OAuth令牌刷新逻辑在Service Worker休眠后失效。

2.2 Chrome 扩展 OAuth 集成的三条路径

在Chrome扩展中集成OAuth 2.0，主要有三条技术路径：

路径一：chrome.identity.getAuthToken（Google专用）

这是Chrome专门为Google账号认证提供的API，适用于需要访问Google服务（Gmail、Drive、Calendar等）的扩展。它会弹出Google登录窗口，用户授权后直接返回OAuth2令牌。

路径二：chrome.identity.launchWebAuthFlow（通用OAuth 2.0）

这是Chrome提供的通用OAuth 2.0授权流API，适用于任何OAuth 2.0提供商（GitHub、Notion、Slack等）。它会在浏览器中打开授权页面，捕获重定向URL并提取授权码。

路径三：自实现OAuth 2.0授权码流（完全控制）

开发者完全自己实现授权码流程——打开授权页面、拦截重定向、交换授权码获取令牌。这种方式最灵活但也最容易出错。

那么，AI扩展应该选哪条路？ 答案取决于你的目标服务。如果你的AI扩展需要访问Google服务，getAuthToken是最便捷的选择。但如果需要访问GitHub、Notion等第三方服务，launchWebAuthFlow是官方推荐方案。下文我们将深入探讨每条路径的细节、安全风险和最佳实践。

三、安全风险：2026年真实发生的 OAuth 令牌窃取事件

在讨论技术方案之前，我们必须先正视一个残酷的现实：Chrome扩展的OAuth集成存在严重的安全隐患，而且这些隐患正在被大规模利用。

3.1 108个恶意扩展：一场针对企业用户的“静默数据虹吸”

2026年4月，安全公司Socket披露了一场大规模恶意扩展攻击：

  • 108个恶意Chrome扩展通过Chrome Web Store传播
  • 超过20,000名企业用户受到影响
  • 54个扩展通过chrome.identity.getAuthToken窃取Google OAuth2 Bearer令牌
  • 45个扩展包含后门行为，在浏览器启动时自动激活
  • 部分扩展每15秒窃取一次Telegram Web会话数据

这些扩展伪装成“Telegram Multi-account”、“Black Beard Slot Machine”、“Page Locker”等看似合法的工具。分析显示，代码中包含俄语注释，暗示这可能是一个恶意软件即服务（MaaS） 运营模式的一部分。

技术核心攻击手法：利用chrome.identity.getAuthToken获取的Bearer令牌，攻击者可以直接访问受害者的Google账号，获取姓名、邮箱、头像等个人信息。

3.2 令牌窃取的三种攻击向量

根据G5网络安全公司的分析报告，Chrome扩展窃取OAuth令牌主要通过以下三种方式：

攻击向量一：拦截重定向URI

如果恶意扩展拥有webRequest权限并匹配了你的授权服务器域名，它可以观察网络请求，在认证完成后的重定向中截取授权码。

攻击向量二：修改重定向URI

更高级的攻击：恶意扩展修改重定向URI，将其指向攻击者控制的服务器。原本发往https://example.com/callback的令牌，被重定向到https://attacker.com/callback。

攻击向量三：内容脚本注入

如果授权回调页面使用了JavaScript处理令牌，恶意扩展可以注入内容脚本，在令牌发送到你的服务器之前将其拦截。

3.3 CVE-2026-13029：认证子系统中的内存破坏漏洞

2026年6月24日披露的CVE-2026-13029进一步敲响了警钟：

  • 影响版本：Google Chrome 149.0.7827.197之前的所有版本
  • 漏洞类型：Web Authentication API中的Use-After-Free
  • 严重等级：高危（Chromium security severity: High）
  • 攻击方式：恶意扩展利用该漏洞触发堆破坏，进而在Chrome进程权限下执行任意代码

这个漏洞揭示了浏览器扩展生态如何成为内存破坏攻击的入口——尤其是当扩展涉及Web Authentication等特权API时。Google的修复方案涉及在认证API处理代码中增加内存管理和额外验证检查。

对于OAuth集成开发者而言，这意味着：不仅要关注OAuth协议本身的安全，还要关注浏览器底层认证API的实现安全。

3.4 客户端凭据保护的“不可能三角”

另一个常见误区是试图在扩展代码中“隐藏”OAuth client_secret。

2026年3月的一篇深度分析明确指出：在浏览器扩展这类完全运行于客户端、不可信环境中硬编码OAuth client_id和client_secret，本质上是一个无法被前端技术彻底解决的安全悖论。

为什么混淆毫无意义？

  • 运行时可逆：所有解密逻辑必须内嵌在JS中，攻击者只需在DevTools中断点调试即可捕获明文凭据
  • 网络层完全暴露：即使代码加密，HTTP(S)流量仍可通过浏览器网络面板、mitmproxy或Wireshark捕获
  • 混淆增加维护成本，不提升实际安全性：它仅延缓低阶攻击者

结论：不要试图在前端“隐藏”任何秘密。正确的方案是架构层面的重构。

四、架构设计：安全 OAuth 集成的四大原则

基于上述安全风险分析，我们总结出Chrome扩展OAuth 2.0集成的四大架构原则：

4.1 原则一：使用 PKCE —— 公共客户端的“护身符”

OAuth 2.0的授权码流程原本假设客户端可以安全存储client_secret。但Chrome扩展是公共客户端（Public Client） ——代码完全暴露，无法安全存储密钥。

PKCE（Proof Key for Code Exchange，RFC 7636）正是为解决这一问题而设计的。 它通过动态生成的code_verifier和code_challenge，确保即使授权码被拦截，攻击者也无法换取令牌。

根据2026年1月的社区讨论，在Chrome扩展中使用PKCE是保护授权码的最佳实践。

PKCE流程示意：

// 1. 生成 code_verifier（43-128字符的随机字符串）
function generateCodeVerifier() {
  const array = new Uint8Array(32);
  crypto.getRandomValues(array);
  return base64UrlEncode(array);
}

// 2. 生成 code_challenge（SHA-256哈希后base64url编码）
async function generateCodeChallenge(verifier) {
  const encoder = new TextEncoder();
  const data = encoder.encode(verifier);
  const hash = await crypto.subtle.digest('SHA-256', data);
  return base64UrlEncode(new Uint8Array(hash));
}

// 3. 授权请求中携带 code_challenge
const authUrl = `https://auth.example.com/authorize?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=YOUR_REDIRECT_URI&
  response_type=code&
  code_challenge=${codeChallenge}&
  code_challenge_method=S256&
  state=${generateState()}`;

// 4. 换取令牌时携带 code_verifier
const tokenResponse = await fetch('https://auth.example.com/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    client_id: 'YOUR_CLIENT_ID',
    code: authorizationCode,
    code_verifier: codeVerifier,
    redirect_uri: 'YOUR_REDIRECT_URI',
    grant_type: 'authorization_code'
  })
});

4.2 原则二：使用 State 参数防御 CSRF

state参数是OAuth 2.0中防御CSRF攻击的标准机制。在发起授权请求时生成一个随机值，在回调中验证该值是否一致。

// 发起授权时
const state = crypto.randomUUID();
await chrome.storage.local.set({ oauth_state: state });

// 回调验证时
const params = new URLSearchParams(redirectUrl.split('?')[1]);
const returnedState = params.get('state');
const storedState = (await chrome.storage.local.get('oauth_state')).oauth_state;
if (returnedState !== storedState) {
  throw new Error('CSRF attack detected!');
}

4.3 原则三：最小权限 + 短期令牌

永远不要请求超出需要的权限。 2026年的恶意扩展攻击表明，过度授权是令牌被滥用的放大器。

具体实践：

  • 限定OAuth scope：只请求必要的API权限
  • 使用短期access_token + refresh_token机制：即使令牌泄露，攻击窗口有限
  • 在服务端实施额外的风控：如IP绑定、设备指纹校验等

4.4 原则四：动态客户端注册 —— 消灭静态密钥

对于需要client_secret的非交互式场景（如客户端凭证模式），动态客户端注册（Dynamic Client Registration, RFC 7591） 是比静态密钥更安全的方案。

核心思想：每个扩展实例在首次启动时，向授权服务器发起注册请求，获取一个唯一的、短期有效的client_id。

// 扩展首次启动时动态注册
async function registerClient() {
  const challenge = await crypto.subtle.digest('SHA-256', 
    new TextEncoder().encode(navigator.userAgent + chrome.runtime.id)
  );
  const signature = await signWithExtensionPrivateKey(challenge);
  
  const res = await fetch('https://auth.example.com/register', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      client_name: 'MyAIExtension',
      token_endpoint_auth_method: 'none',
      jwks_uri: 'https://ext.example.com/jwks.json',
      software_statement: btoa(JSON.stringify({ challenge, signature }))
    })
  });
  
  const { client_id } = await res.json();
  await chrome.storage.local.set({ client_id });
}

优势：服务端可按client_id追踪、限流、冻结异常实例；client_id泄露后影响范围可控。

五、部署方案：三种 OAuth 集成方式的实战指南

5.1 方案一：chrome.identity.getAuthToken —— Google 服务专用

这是最简单的方案，适用于只需要访问Google服务的AI扩展（如AI邮件助手访问Gmail、AI文档工具访问Google Drive）。

配置步骤：

  1. 在Google Cloud Console中创建OAuth 2.0凭据

    • 应用类型选择“Chrome应用”
    • 填写扩展的ID（可从Chrome Web Store获取）

  2. 在manifest.json中声明权限：

{
  "manifest_version": 3,
  "name": "AI Assistant",
  "permissions": [
    "identity"
  ],
  "oauth2": {
    "client_id": "YOUR_GOOGLE_CLIENT_ID",
    "scopes": [
      "https://www.googleapis.com/auth/gmail.readonly",
      "https://www.googleapis.com/auth/drive.readonly"
    ]
  }
}
  1. 获取令牌：
// 在Service Worker中
chrome.identity.getAuthToken({ interactive: true }, function(token) {
  if (chrome.runtime.lastError) {
    console.error(chrome.runtime.lastError);
    return;
  }
  // token 就是 OAuth2 access_token
  // 可以用它调用Google API
  fetch('https://www.googleapis.com/gmail/v1/users/me/messages', {
    headers: { 'Authorization': `Bearer ${token}` }
  });
});

⚠️ 安全警告：根据2026年4月的安全报告，54个恶意扩展正是利用getAuthToken窃取用户令牌。使用此API时必须严格审查扩展的权限范围，并确保不将令牌传输到不受信任的服务器。

5.2 方案二：chrome.identity.launchWebAuthFlow —— 通用 OAuth 2.0

这是Chrome官方推荐的通用OAuth 2.0集成方案，适用于GitHub、Notion、Slack等任何OAuth 2.0提供商。

核心流程：

// 1. 构造授权URL
const authUrl = new URL('https://github.com/login/oauth/authorize');
authUrl.searchParams.set('client_id', 'YOUR_CLIENT_ID');
authUrl.searchParams.set('redirect_uri', chrome.identity.getRedirectURL());
authUrl.searchParams.set('response_type', 'code');
authUrl.searchParams.set('scope', 'read:user repo');
authUrl.searchParams.set('state', generateState());

// 2. 启动WebAuthFlow
chrome.identity.launchWebAuthFlow({
  url: authUrl.toString(),
  interactive: true
}, async function(redirectUrl) {
  if (chrome.runtime.lastError) {
    console.error(chrome.runtime.lastError);
    return;
  }
  
  // 3. 从重定向URL中提取授权码
  const params = new URLSearchParams(redirectUrl.split('?')[1]);
  const code = params.get('code');
  const state = params.get('state');
  
  // 4. 验证state（防CSRF）
  if (state !== storedState) {
    throw new Error('CSRF attack detected');
  }
  
  // 5. 用授权码换取access_token（必须通过你的后端服务完成！）
  const tokenResponse = await fetch('https://your-backend.com/exchange', {
    method: 'POST',
    body: JSON.stringify({ code })
  });
  const { access_token } = await tokenResponse.json();
});

关键安全要点：

永远不要在扩展中直接使用client_secret换取令牌！ 正确的做法是在你的后端服务中完成/token交换，扩展只负责获取授权码。

根据IETF 2025年12月发布的《OAuth 2.0 for Browser-Based Applications》规范，浏览器中的OAuth客户端不应持有任何长期凭证。

5.3 方案三：自实现授权码流 —— 完全控制

对于有特殊需求的场景（如非标准OAuth 2.0实现、自定义UI等），可以完全自己实现授权流程。

核心步骤：

  1. 使用chrome.tabs.create()或chrome.windows.create()打开授权页面
  2. 使用chrome.tabs.onUpdated或webRequestAPI监听重定向
  3. 从重定向URL中提取授权码
  4. 通过后端交换令牌

⚠️ 这种方案最复杂也最容易出错，尤其是在MV3中，webRequest的阻塞能力被大幅削弱。除非有特殊需求，否则优先使用launchWebAuthFlow。

5.4 方案对比

维度 getAuthToken launchWebAuthFlow 自实现
适用服务 仅Google 任何OAuth 2.0提供商 任何
实现复杂度 ⭐ 最简单 ⭐⭐ 中等 ⭐⭐⭐⭐⭐ 最复杂
PKCE支持 内置 需自行实现 需自行实现
CSRF防护 内置 需自行实现state 需自行实现
令牌存储 Chrome自动管理 需自行管理 需自行管理
MV3兼容性 ✅ 完全兼容 ✅ 完全兼容 ⚠️ 受webRequest限制
安全风险 ⚠️ 2026年有大规模滥用案例 ✅ 相对安全（需正确实现） ⚠️ 容易出错

六、生态工具：让 OAuth 集成事半功倍

6.1 @neiro21/solid-client-authn-webext —— Solid 生态的扩展适配器

2026年5月8日发布的@neiro21/solid-client-authn-webext 0.3.0版本，是一个值得关注的OAuth集成工具。

这个库是Inrupt的Solid客户端认证库的fork版本，专门为Web浏览器扩展适配。它使用浏览器的Identity API执行OAuth 2.0流程的第一部分（获取授权码），其余部分与@inrupt/solid-client-authn-browser相同。

使用示例：

import { Session } from '@neiro21/solid-client-authn-webext';

const solidSession = new Session();
solidSession.login({
  oidcIssuer: "https://solidcommunity.net",
  clientName: "MyAIExtension"
}).then(() => {
  if (solidSession.info.isLoggedIn) {
    // 访问Solid Pod中的数据
    const myDataset = await getSolidDataset(
      "https://somepod.solidcommunity.net/somepath",
      { fetch: solidSession.fetch }
    );
  }
});

适用场景：如果你的AI扩展需要与Solid生态（去中心化数据存储）集成，这个库可以大幅简化OAuth流程。

6.2 Entra Auth Tracer —— 身份认证流调试利器

2026年3月26日发布的Entra Auth Tracer是一个开源的Chromium扩展，用于深度检查身份认证流量。

它支持：

  • Microsoft Entra (Azure AD)
  • Okta
  • AWS Cognito
  • Google/Firebase
  • IdentityServer/Duende
  • 任何兼容OAuth 2.x或OIDC的端点

对于OAuth集成开发者，这是一个 invaluable 的调试工具——可以实时查看授权请求、令牌交换、刷新等全流程的HTTP流量。

6.3 webextension-polyfill —— 跨浏览器兼容

对于需要同时支持Chrome、Firefox、Edge的扩展，webextension-polyfill是必备工具。它将各浏览器的扩展API统一为Promise风格，让OAuth集成代码在不同浏览器间无缝运行。

七、竞品对比：Firefox、Safari、Edge 的 OAuth 支持

虽然本文聚焦Chrome扩展，但了解各浏览器的差异有助于做出更明智的架构决策。

7.1 Firefox

Firefox的Manifest V3实现与Chrome存在差异：

  • identity API：Firefox也支持browser.identity.launchWebAuthFlow，API签名与Chrome基本一致
  • getAuthToken：Firefox没有直接等价的Google专用API
  • 权限模型：Firefox对MV3的实现更接近MV2，webRequest的阻塞能力保留更完整

7.2 Safari

Safari的扩展API相对有限：

  • OAuth支持：需要通过browser.runtime.sendNativeMessage与原生应用通信来实现OAuth
  • 限制更多：Safari扩展的权限和API访问范围更窄

7.3 Microsoft Edge

Edge基于Chromium，API与Chrome高度兼容：

  • 支持chrome.identity.getAuthToken和chrome.identity.launchWebAuthFlow
  • 但Edge的扩展商店审核政策与Chrome不同

对于AI扩展开发者：如果目标是多浏览器发布，建议以Chrome的launchWebAuthFlow为基础实现，配合webextension-polyfill处理API差异。

八、实战案例：一个 AI 邮件助手的 OAuth 集成

让我们通过一个完整的实战案例，将上述原则串联起来。

场景：一个AI驱动的Gmail助手扩展，需要读取用户的邮件内容，用AI生成回复建议。

8.1 架构设计

┌─────────────────────────────────────────────────────────┐
│                    Chrome 扩展                          │
│  ┌─────────────────────────────────────────────────┐   │
│  │  Service Worker (MV3)                          │   │
│  │  - 使用 chrome.identity.getAuthToken 获取令牌   │   │
│  │  - 令牌存储在 chrome.storage.local             │   │
│  │  - 定时刷新令牌（before expire）               │   │
│  └─────────────────────────────────────────────────┘   │
│  ┌─────────────────────────────────────────────────┐   │
│  │  Content Script (注入Gmail页面)                │   │
│  │  - 读取邮件内容                                │   │
│  │  - 通过 Message Passing 与 Service Worker 通信 │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘
                            │
                            ▼
              ┌─────────────────────────┐
              │   Google Gmail API      │
              │   (OAuth 2.0 保护)      │
              └─────────────────────────┘

8.2 核心代码实现

manifest.json：

{
  "manifest_version": 3,
  "name": "AI Gmail Assistant",
  "permissions": [
    "identity",
    "storage"
  ],
  "host_permissions": [
    "https://www.googleapis.com/*"
  ],
  "oauth2": {
    "client_id": "YOUR_CLIENT_ID",
    "scopes": [
      "https://www.googleapis.com/auth/gmail.modify"
    ]
  },
  "background": {
    "service_worker": "background.js"
  }
}

background.js（Service Worker） ：

// 令牌管理
async function getValidToken() {
  const stored = await chrome.storage.local.get(['token', 'expiry']);
  
  // 如果令牌有效，直接返回
  if (stored.token && stored.expiry > Date.now()) {
    return stored.token;
  }
  
  // 否则获取新令牌
  return new Promise((resolve, reject) => {
    chrome.identity.getAuthToken({ interactive: true }, async (token) => {
      if (chrome.runtime.lastError) {
        reject(chrome.runtime.lastError);
        return;
      }
      
      // 获取令牌过期时间（通过解析JWT或调用tokeninfo API）
      const expiry = await getTokenExpiry(token);
      await chrome.storage.local.set({ 
        token, 
        expiry: Date.now() + (expiry - 60) * 1000 // 提前60秒刷新
      });
      resolve(token);
    });
  });
}

// 调用Gmail API
async function fetchEmails() {
  const token = await getValidToken();
  const response = await fetch(
    'https://www.googleapis.com/gmail/v1/users/me/messages?maxResults=10',
    { headers: { 'Authorization': `Bearer ${token}` } }
  );
  return response.json();
}

// 监听内容脚本消息
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.type === 'FETCH_EMAILS') {
    fetchEmails().then(sendResponse);
    return true; // 异步响应
  }
});

8.3 安全加固措施

  1. 最小权限：只请求gmail.modify而非gmail.full
  2. 令牌短期化：主动在过期前刷新，减少令牌泄露窗口
  3. 不传输令牌到第三方：令牌仅在扩展内部使用，不发送到任何AI服务后端
  4. AI处理在后端完成：扩展只负责获取邮件数据，AI分析在自有后端完成，通过API密钥认证

九、趋势判断：2026年及以后的 OAuth 安全方向

9.1 DPoP：发送方约束令牌的兴起

2025年1月，IETF发布了RFC 9700（OAuth 2.0安全最佳现行实践更新），将发送方约束令牌（sender-constrained token） 列为防范被盗令牌滥用的推荐方案。

DPoP（Demonstrating Proof-of-Possession，RFC 9449） 要求客户端在每次使用令牌时附带一个由私钥签名的JWT，证明令牌的“持有者”身份。即使令牌被窃取，攻击者也无法伪造签名。

对于Chrome扩展开发者：虽然DPoP目前在扩展生态中尚未普及，但这是一个明确的技术方向。建议关注各大OAuth提供商对DPoP的支持进展。

9.2 零信任架构在扩展生态的落地

2026年的恶意扩展事件表明，浏览器已经成为新的企业安全边界。

Google的企业安全指南建议：

  • 测试扩展：在部署前全面测试
  • 基于权限决定允许哪些扩展
  • 通过策略管理扩展行为

对于AI扩展开发者而言，这意味着：

  • OAuth集成必须经过安全审计
  • 必须遵循最小权限原则
  • 建议采用动态客户端注册替代静态密钥

9.3 AI扩展的特殊挑战

AI驱动的Chrome扩展在OAuth集成上面临独特的挑战：

挑战一：数据流向复杂——AI扩展通常需要将用户数据发送到AI服务（OpenAI、Anthropic等）进行处理。这意味着OAuth令牌和用户数据可能经过多个系统。

解决方案：采用令牌中继模式——扩展获取令牌后，仅用于从第三方服务获取原始数据，AI处理在自有后端完成，且自有后端绝不接触用户的OAuth令牌。

挑战二：自动化程度高——AI扩展往往需要后台自动执行任务（如定时总结邮件），这意味着需要刷新令牌的自动化机制。

解决方案：在Service Worker中实现令牌刷新定时器，利用chrome.alarms API定期检查并刷新即将过期的令牌。

挑战三：用户信任门槛高——AI扩展请求OAuth权限时，用户对“AI访问我的数据”天然存在戒心。

解决方案：在授权前提供清晰的隐私说明，明确告知数据如何使用、是否存储、是否用于模型训练。

十、总结与实践建议

10.1 核心要点回顾

要点 说明
MV3是唯一选择 Manifest V2已退出历史舞台，新扩展必须使用MV3
PKCE是标配 公共客户端必须使用PKCE保护授权码
永不存储client_secret 前端无法安全存储任何秘密
使用state防CSRF 这是OAuth 2.0的基本安全要求
最小权限原则 只请求必要的scope和扩展权限
令牌短期化 使用refresh_token机制，缩短access_token有效期
后端完成令牌交换 绝不在扩展中直接用client_secret换令牌

10.2 决策流程图

你的AI扩展需要访问什么服务？
    │
    ├── 仅Google服务（Gmail/Drive/Calendar等）
    │       └── 使用 chrome.identity.getAuthToken
    │           ├── 配置oauth2在manifest.json
    │           ├── 声明最小scope
    │           └── 令牌存储在chrome.storage
    │
    ├── 任何OAuth 2.0提供商（GitHub/Notion/Slack等）
    │       └── 使用 chrome.identity.launchWebAuthFlow
    │           ├── 实现PKCE
    │           ├── 实现state验证
    │           └── 后端完成/token交换
    │
    └── 特殊需求（非标准OAuth/自定义UI）
            └── 自实现授权码流
                ├── 注意MV3中webRequest限制
                └── 强烈建议使用launchWebAuthFlow替代

10.3 立即行动清单

如果你是Chrome扩展开发者，建议立即执行以下检查：

  1. 检查manifest.json：是否还在使用manifest_version: 2？立即迁移到MV3
  2. 检查OAuth实现：是否使用了PKCE？是否验证了state参数？
  3. 检查权限：是否请求了超出实际需要的scope或扩展权限？
  4. 检查令牌存储：access_token是否持久化到了chrome.storage？（MV3必须）
  5. 检查刷新逻辑：Service Worker休眠后，令牌刷新是否还能正常工作？
  6. 安全审计：是否将OAuth令牌传输到了任何第三方服务器？

10.4 最后的思考

2026年是Chrome扩展生态的关键转折点。Manifest V3的全面落地、OAuth安全威胁的集中爆发、AI扩展的井喷式增长——这三条线交织在一起，对开发者提出了前所未有的要求。

安全不再是“锦上添花”，而是“生存底线”。 正如2026年4月那108个恶意扩展所证明的——一次OAuth集成的疏忽，可能导致数万用户的数据泄露。

但挑战也意味着机遇。那些能够正确、安全地集成OAuth 2.0的AI扩展，将在2026年及以后的市场中占据决定性优势。 用户只会信任那些尊重他们数据隐私和安全的应用。

从现在开始，把OAuth安全当作你AI扩展的核心竞争力来建设。

# chrome # 人工智能 # 安全
Logo
加入AMD AI开发者计划！

免费领 150 小时云算力，进群参与显卡、AI PC 幸运抽奖

更多推荐

cover

WSL2 GPU 直连与 vLLM 大模型推理

avatar AMD开发者中国社区

DCU使用技术报告_中篇_gfx936_DCU_Qwen3.5-27B_Triton-ROCm_Attention与GEMV深度优化实战

系列文章中篇。上篇解决了环境、基线和 Profile 的可信度问题；这一篇进入算子层，记录专用 Prefill Attention、Q10/Q20 Query 复用、Gate/Up Triton GEMV，以及一批看起来合理但最终没有采用的实验。

avatar AMD开发者中国社区

DCU使用技术报告_下篇_gfx936_DCU_Qwen3.5-27B_rocBLAS-hipBLASLt调优、vLLM工程化与踩坑实战

这次做 DCU 推理优化，最容易上瘾的是看一个 kernel 从 0.50 ms 变成 0.33 ms。真正难的却是后面的判断：它一层有多少次调用，是否命中 CUDA Graph，是否改变生成路径，是否只在某个 chunk 上有效，部署到另一个容器后会不会悄悄回退。Profile 找热点，真实形状做微基准，局部候选用 guard 接入，服务结果决定去留，精度最后否决。DCU、ROCm、Triton

avatar AMD开发者中国社区