OAuth 是好技术，但 Google 和 Microsoft 将它变成了准入门槛

OAuth 是安全性的进步

放弃基本身份验证、长期有效的密码和权限过大的凭据，是正确的决定。OAuth 支持有限权限、短期访问令牌、可撤销的连接，让人们更好地控制应用程序实际能够执行的操作。

这是一项开放标准，说明应用程序如何代表用户请求并获得访问权限。标准本身并不要求开发者向平台运营者提交商业文件、组织证明、演示视频或准入申请。这额外的一层来自平台生态的规则。

开放标准仍可能变成封闭的关卡

SMTP 和 IMAP 诞生于以互操作性为基础的互联网。服务商可以运行邮件服务器，开发者可以制作客户端，双方通过公开文档中的标准通信。

OAuth 并没有破坏这种开放性。但如果邮箱访问还取决于平台所有者的批准，决定性的问题就发生了变化：究竟是用户授权应用程序，还是 Google 或 Microsoft 决定这个应用程序是否有资格获得授权？

安全审查要求应用程序证明其以安全且符合特定目的的方式处理用户数据。准入把关则反复要求发布者解释应用程序为何可以存在于该生态中。本文认为二者的区别很重要，同时承认邮箱数据的敏感性。

Microsoft 365：用户同意往往止步于租户边界

本文所述的 Microsoft 障碍通常不是 Google 式的视频审查，而是 Microsoft Entra ID、发布者验证、管理员同意和每个 Microsoft 365 租户策略之间的相互作用。

Microsoft 建议将用户同意限制为已验证的发布者和指定的低风险权限。管理员可以进一步限制或关闭该功能。即使用户明确希望连接邮箱，也仍可能被告知需要管理员批准。

对于较新的多租户应用程序，发布者验证也可能具有决定性作用。除其他要求外，发布者还需要一个经过验证、与应用注册关联的 Microsoft AI Cloud Partner Program 账户。这是可以理解的信任信号，却也将开放授权的可用性与 Microsoft 的商业和合作伙伴流程关联起来。

Google 和 Gmail：权限范围审查可能成为产品瓶颈

Gmail 的流程更加集中化。文章发表时所述的策略分类将 gmail.send 列为敏感权限，将 gmail.readonly 列为受限权限。根据具体用途，需要这些权限的公开应用可能必须提供品牌和域名证明、精确的权限范围说明以及演示视频。

视频必须展示完整的 OAuth 流程、实际的同意页面，以及每个申请权限范围对应的功能。如果权限理由被拒绝，或者审查者认为演示与应用不一致，后续可能需要回答更多问题、重新录制或再次提交。

原文引用了 Google 不具约束力的估计：品牌验证需要两到三个工作日，敏感权限需要十个工作日，受限权限最长需要六周。在服务器上存储或传输受限 Gmail 数据，还可能需要每年重复进行安全评估。这些是原始发表时对应的策略说明和估计，并非关于审批时间的新承诺。

100 名用户的上限具有实际后果

在测试模式下，访问仅限于最多 100 名明确列出的测试用户；根据所链接的 Google 指南所述条件，其授权会在七天后到期。未经验证的应用还可能受到整个存续期间最多 100 名新用户的限制。

如果某个敏感或受限权限范围被拒绝，用户便无法继续访问该未获批准的范围。因此，上限或拒绝并不只是管理层面的提醒：它可能直接停止用户想要启用的产品功能。

Hassolux 为什么需要这些权限

Hassolux 是面向建筑和服务企业的工作平台，将项目、文档、发票和通信整合到可追溯的工作流程中。其可选邮箱连接由获得授权的用户主动启用。

对于 Microsoft 365，委托权限 Mail.Read 和 Mail.Send 用于代表已登录用户读取来信，以及发送该用户明确要求的文档邮件。对于 Gmail，gmail.readonly 用于获取选定的邮件及 PDF/XML 附件，而 gmail.send 单独用于用户主动发起的外发邮件。

Hassolux 仅搜索用户选定的时间段，读取发件人、主题和接收时间，并导入支持的 PDF 或 XML 附件以处理发票。它不会移动、标记、修改或删除 Gmail 邮件。发送是独立功能，只有在用户执行具体操作后才会发生。连接可以移除，也可以额外在服务商处撤销授权。

在这里，要求使用更小的权限范围可能在技术上产生矛盾。仅允许访问元数据的权限不会提供邮件内容或发票附件；应用无法导入自己无权读取的文档。对于这一可见功能，申请 gmail.readonly 是因为它是能够提供所需访问能力的最小 Google 权限，而非为防万一收集更广泛的权限。

我们的经历：多次演示后仍遭拒绝

对于 Hassolux，Google 验证所需的工作远不止实现集成。我们反复制作演示视频、等待审查周期、回复进度邮件，并解释为什么必须使用该权限范围。拒绝这一范围，取消的不只是抽象的 API 权限，而是用户希望连接自己邮箱所要使用的功能。

敏感邮件数据确实需要严格的安全要求。但审查仍必须区分过度收集与技术上必需的最小权限。否则，最小权限原则便无法满足：平台没有提供更小且可用的范围，却又以范围过大为由拒绝现有权限。这是作者对自身审查经历的描述和论证，并不意味着所有应用都会受到同样的对待。

公平的验证流程应当提供什么

以下改进建议旨在保留保护措施，同时让独立集成具备可行性。

• 可提前核查的明确标准：开发者应在实现之前知道哪些用途是允许的。
• 具体且容易理解的决定：拒绝时应指出具体的技术问题或隐私方面的不符之处。
• 适度的证明要求：评估数据流、存储位置和实际风险，而不是主要考虑发布者的规模。
• 可复用的审查结果：产品的小幅改动不应导致整个证明流程从头开始。
• 有实际意义的技术申诉：考虑服务商没有提供更小且能够正常工作的权限范围的情况。
• 有效的用户选择：知情同意和随时撤销授权的权利，应比平台一刀切的限制更有分量。

开放授权应当保持开放

我们支持 OAuth、更强的身份验证和对用户数据的一贯保护。正因为如此，建立在它之上的审批机制才必须允许被批评。安全应保护人们免受有害应用的侵害，而不是轻率地抬高准入门槛，或加强平台所有者对可互操作软件的控制。

一项标准可以在纸面上是开放的。实践中的开放，还需要独立开发者、初创公司和较小的软件企业能够在透明、公平的条件下使用它。互联网的未来不应依赖少数平台为每个技术上必要的集成发放许可。