Google OAuth 有点坏了（某种程度上）
最近被讨论的 Google OAuth 行为允许员工使用邮箱别名（如 [email protected]）创建独立的 Google 账户，而这些账户可能会脱离公司控制，从而在离职后仍可能保留对 Slack 或 Zoom 等第三方应用的访问权限。评论者认为，这与其说是 Google 实现中的缺陷，不如说是 OAuth/OIDC 被广泛误用，尤其是把 email 当作稳定、可信的标识符，而不是使用正确的 subject ID 和验证流程。讨论还引出了对现代 Web 认证标准复杂性的担忧，以及像 Google $1,337 赏金这样的漏洞奖励是否真能有效激励负责任披露的问题。
漏洞赏金价值与 Google 的回应
- 许多人认为，考虑到潜在影响，$1337 的奖励只是象征性的，并将其与其他地方类似问题的更高赏金作了不利比较。
- 也有人认为，对于他们看来只是已记录的行为或一个“脚枪”（footgun），而不是经典漏洞，这个奖励已经很慷慨了，并对它竟然还得到了奖励感到惊讶。
- 有些人指出，从分流到奖励之间延迟数月对大公司来说很常见，但他们觉得真正的问题是金额太低，而不是时间。
到底是谁的责任？Google 还是集成方？
- 一派认为，缺陷主要在第三方应用（Slack、Zoom 等）身上，因为它们：
- 将 email claim 作为主要标识符。
- 根据邮箱域名推断组织归属。
- 另一派则认为 Google 也应承担责任，因为：
- 带加号的别名和非组织 Google 账户共享相同的邮件路由，但对 Workspace 管理员不可见。
- Google 理论上可以阻止在已被 Workspace 客户认领的域名上创建新的个人账户，或提供更强的控制。
问题的技术核心
- Google 将
user+suffix@domain（以及点号变体）视为与user@domain相同的邮箱，但又允许使用这些地址创建独立的 Google 账户。 - 员工可以先用这种别名预先注册一个非组织 Google 账户，之后即使其正式账户被取消配置，仍可通过“使用 Google 登录”访问企业 SaaS。
- 影响取决于 SaaS 是否只依赖 email claim 进行授权；一些评论者强调，OIDC 文档中明确不建议这样做。
缓解措施与最佳实践
- 讨论中推荐的模式：
- 使用
iss+sub作为稳定的身份键，而不是 email。 - 永远不要仅基于 email 域授予权限。
- 对企业 SaaS 账户要求显式开通或允许列表。
- 发送独立的邮件验证，或使用“magic link” + 2FA；批评者指出这会带来 UX 缺点和钓鱼风险。
- 为 B2B 控制优先使用 SAML/SCIM 或专用的企业 IdP。
- 使用
更广泛的 OAuth/OIDC 与身份认同争论
- 多位参与者认为，委托认证和 OIDC 过于复杂、沟通不清，而且容易配置错误。
- 对 email 是否应被视为主要身份存在分歧：
- 优点：全球都能理解，使用广泛。
- 缺点：不稳定、可重新分配、可共享，而且在不同 IdP 之间并不唯一。
- 一些人认为，这一事件体现的是整个 Web 身份验证生态系统的混乱，而不是单一的“Google OAuth 坏了”的时刻。