Google将于2026年8月5日起对API新Token强制Passkey验证，8月19日起UI敏感操作亦需通行密钥。多账号运营者面临反检测浏览器隔离失效、新账号7天信任期、跨设备蓝牙验证阻断及共享登录不可用等挑战。建议提前刷新OAuth Token、注册Passkey度过信任期，或转向MCC架构、硬件密钥及Service Account作为长期合规方案。
Tags:
做Google Ads联盟营销投放的人，这两天应该都收到这封邮件了吧。
"自 8 月 19 日起，您需要使用 Google 通行密钥才能在账号中执行某些敏感操作。"
改账号权限、改账单、绑新用户，不再接受密码+验证码。
必须用通行密钥（Passkey）。
更早的8月5号，API层面生成新的OAuth刷新令牌，也必须过Passkey验证。
TOTP验证器、短信验证码，统统不认。
这对只有一个账号的广告主来说，只是多录一次指纹的事。
但对同时跑5个、10个Ads账号做Affiliate Marketing投放的人来说，这是一次底层架构级的冲击。
先搞清楚Passkey到底是什么
Passkey不是密码的升级版，是完全不同的东西。
关键词：绑定设备、绑定域名、绑定Google账号、不可复制。
这四个"绑定"，每一个都在打多账号体系的命门。
多Ads账号的联盟客，具体遇到什么问题
问题一：反检测浏览器的隔离逻辑被击穿
跑多账号的联盟客，核心依赖是反检测浏览器（Multilogin、GoLogin、AdsPower等）。
每个浏览器配置文件有独立的cookie、canvas指纹、WebGL哈希、UA字符串。
对Google来说，每个配置文件"看起来"像一台独立的电脑。
但Passkey验证的时候，它要的不是浏览器指纹，而是设备级别的密码学证明。
你的反检测浏览器有50个配置文件，但Passkey验证的时候，Google看到的是同一个人的指纹在50个"不同设备"上做敏感操作。
问题二：7天信任延迟锁死新账号节奏
新注册的Passkey最多需要等7天才能被系统信任。
这意味着什么？
对做联盟营销投放的人来说，7天空窗期的成本非常具体。
旺季一天投放预算可能$500以上，7天就是$3500的机会成本。
问题三：跨设备验证暴露物理位置
如果你在电脑上操作，但Passkey在手机上，Google的跨设备方案是这样的：
1. 电脑弹出QR码
2. 手机扫描QR码
3. 手机做生物识别
4. 通过蓝牙低功耗（BLE）确认两台设备在物理近距离范围内
蓝牙验证，目的是确认"操作的人真的在设备旁边"。
如果你用VPS或云服务器跑广告（很多联盟客这么干），这个步骤过不了。
云服务器没有蓝牙，物理距离验证直接失败。
问题四：共享登录彻底死亡
以前团队里可以共享一个Ads账号的密码，多个人用同一个账号操作。
Passkey的设计原则就是：一个人一个密钥，绑定一个人的生物特征，不可转让。
Google官方措辞很直接："Passkeys cannot be shared; they're bound to an individual's device and biometric."
团队协作只能走正规路线：每人用独立邮箱获得独立权限。
以前一个人管10个账号靠密码本就行的操作模式，结束了。
影响程度分级
不是所有多账号联盟客受到的冲击都一样大。
有哪些应对方案
方案一：硬件安全密钥（YubiKey）
FIDO2硬件密钥可以作为Passkey使用。
优势：不绑定特定设备，插哪台电脑都能用。
限制：仍然是"一个密钥绑定一个Google账号"的逻辑，不能一个密钥认证多个账号。
方案二：转向MCC正规架构
如果你的多账号确实是服务不同客户或不同业务线，最合规的做法是用Google Ads Manager Account（MCC）。
一个登录入口管理所有子账号，Passkey验证一次，全部子账号都能操作。
但这意味着所有账号在Google眼里是"关联"的。
如果一个子账号违规，可能波及整个MCC。
对联盟营销来说，账号之间的"防火墙"是命根子。
MCC把这道墙拆了。
方案三：Service Account走API
Google明确说了：Service Account工作流不受Passkey要求影响。
如果你的投放操作主要通过API完成（自动化出价、批量上传、数据拉取），可以把认证从个人OAuth迁移到Service Account。
限制：Service Account不能做所有操作。账号链接、用户权限变更、账单修改这些"敏感操作"仍然需要人工Passkey验证。
方案四：提前锁定现有Token
现有的OAuth刷新令牌继续有效，不需要重新认证。
这是一个时间窗口。
8月5号之前，把所有账号的Token刷新一遍，确保每个连接都是活的。
8月19号之前，为每个账号注册好Passkey并等过7天信任期。
之后只要不主动断开连接，就不会触发Passkey验证。
问题是：Token不是永久的。Google可以在任何时候要求重新认证。
这只是争取时间的缓冲，不是长期方案。
时间线总结
这件事的本质
Google推Passkey，表面上是安全升级，底层逻辑是账号实名化+设备强绑定。
当每个账号都绑定一个真人的生物特征和物理设备，"一人多号"的操作模式就失去了技术基础。
这不是一个能通过换工具解决的问题。
这是Google从根上改变了"账号"的定义，从"一组凭证"变成了"一个活人"。
联盟营销里跑多账号的合理需求确实存在（不同细分领域、不同地区、风险隔离）。
但Google不区分你是为了风险管理还是为了规避封号。
在它的系统里，一个人就应该对应一个身份。
能做的事：尽快把操作架构从"绕过检测"转向"合规多账号管理"。
MCC+Service Account+硬件密钥的组合，是目前唯一站得住脚的长期方案。
两个日期卡在那里：8月5号API锁死，8月19号UI锁死。
现在注册Passkey，刚好赶上7天信任期。
再拖就来不及了。
没有评论:
发表评论