OAuth 2.0 和 Service Account 有什么区别？理清 Google API 认证

关于本文

关于本文
本文采用结合生成式 AI 的自动化流程创建。通过查阅 Google Identity / Google Cloud IAM 的官方一手资料，并以“以谁的权限、访问什么”这一易于初学者理解的维度，对 OAuth 2.0 和 Service Account 进行了梳理。

信息核实基准日：2026年9月19日
Google 的认证方式、推荐配置和官方网址可能会发生变化。本文已核实上述基准日时的官方信息。

验证状态：已于 2026 年 9 月 19 日核实 Google Identity / Google Cloud IAM 官方信息。

一句话总结

使用 Google API 时，会一下子涌现出 OAuth 2.0、Service Account、API Key、Access Token 等许多相似的词汇。首先只需记住一点。

• OAuth 2.0：用户授权“允许该应用在一定程度上使用我的数据”的机制

• Service Account：赋予服务器、批处理等非人类处理的身份账号

也就是说，它们之间并非谁更高阶，而是以谁的身份来调用 API有所不同。

在整个 Google 体系中处于什么位置？

这两个服务与其说是能独立完成业务的服务，不如说是为了通过 API 安全使用 Gmail、Calendar、Drive、Google Cloud 等服务而存在的底层组件。

flowchart LR
  USER[利用者] --> APP[アプリ]
  APP --> AUTH{誰としてアクセス?}
  AUTH -->|利用者の許可を受ける| OAUTH[OAuth 2.0]
  AUTH -->|アプリ自身として動く| SA[Service Account]
  OAUTH --> TOKEN[Access Token]
  SA --> CRED[短期資格情報]
  TOKEN --> API[Google API]
  CRED --> API
  IAM[IAM / 対象サービスの権限] --> API

面向初学者的术语梳理

认证（Authentication）是确认“你是谁？”的过程。类似于登录并核实身份。

授权（Authorization）是决定“该人员或应用可以做什么？”的过程。即使确认了身份，也不意味着能够读取所有数据。

OAuth 2.0主要是用于授权的标准机制。它无需将密码本身交给应用，即可授予诸如“仅允许读取日历”之类的有限权限。

Service Account是在 Google Cloud 中管理的、专为应用程序或计算处理而非人类准备的身份标识（ID）。

Access Token是向 API 表明“我已获得授权”的短期通行证。

Scope是在 OAuth 中表示“请求授权到什么程度”的范围。

OAuth 2.0 的流程是怎样的？

sequenceDiagram
  participant U as 利用者
  participant A as アプリ
  participant G as Google認可画面
  participant API as Google API
  U->>A: 機能を使う
  A->>G: 必要なScopeで認可を要求
  G->>U: このアクセスを許可しますか？
  U->>G: 許可
  G-->>A: Authorization Code
  A->>G: CodeをTokenへ交換
  G-->>A: Access Token
  A->>API: Access Token付きでAPI呼び出し
  API-->>A: 許可範囲のデータ

在 Web 应用等场景中，其大致流程如此。由于实现方式因应用类型而异，Google 官方建议使用提供的身份验证库，而不是自己构建 OAuth 端点。

Service Account 的流程是怎样的？

sequenceDiagram
  participant W as バッチ/サーバー
  participant ID as Service Account
  participant IAM as IAM
  participant API as Google Cloud API
  W->>ID: 実行環境に関連付けたIDを利用
  ID->>IAM: 必要な権限を確認
  IAM-->>W: 短期資格情報
  W->>API: 資格情報付きでAPI呼び出し
  API-->>W: 許可された処理結果

在 Google Cloud 上，最典型的方案是将 Service Account 关联到运行资源并使用短期凭证。在外部环境中，Workload Identity Federation 也是一种选择。

虽然也可以使用 Service Account JSON key，但 Google 明确指出了无法妥善管理密钥时的安全风险，并指导我们在有更安全的替代方案时优先选择替代方案。

对比 OAuth 2.0 与 Service Account

重要的一点是，“因为是自动处理，所以就一定要用 Service Account”这种想法是错误的。需要结合各个 API 的认证规范以及访问对象的数据归属来综合决定。

在工作中如何区分使用？

普通用户 / 行政人员

例如，如果某个工具用于将你自己的 Google Calendar 日程整理到 Excel 或 CSV 中，那么“授权此工具读取我的日程”就是一个容易理解的 OAuth 2.0 示例。在此过程中，重点在于检查授权界面请求的权限是否过于宽泛。

IT 管理员

比起创建大量的 Service Account，更重要的是通过 IAM 来管理谁可以使用哪个 Service Account、以及可以访问什么内容。切勿轻易分发长期有效的 JSON key，应当优先遵循最小权限原则和短期凭证。

开发人员

首先要确定是“用户委托”还是“工作负载身份”。然后确认目标 API 支持的认证方式、所需的 Scope/IAM Role 以及运行环境。在 Google Cloud 客户端库中使用应用默认凭据（ADC），可以设计成不易在不同环境中随处修改认证代码的架构。

如果你熟悉 Microsoft，应该如何思考？

切勿将“Service Account = Microsoft 的某某事物”直接画等号，应当理解为“为非人类处理赋予身份和最小必要权限”这一思路是相通的，这样理解才更安全。

API Key 是完全不同的另一种东西

API Key 用于识别 API 调用方的 Project 或应用，但它与需要用户同意的 OAuth、或是作为工作负载主体的 Service Account 在角色上截然不同。是否可用以及限制方法因各 API 而异。

安全试用：检查 ADC 的状态

Google Cloud 系列客户端库经常会用到 ADC（Application Default Credentials）。ADC 是一种自动从运行环境中查找可用凭证的机制。

在本地开发中，将用户凭证配置到 ADC 的典型命令如下。

gcloud auth application-default login

应该检查什么？ 确认浏览器认证已完成，并且已创建用于 ADC 的本地凭证。

成功的条件是什么？ 之后支持 ADC 的客户端库能够在代码中直接找到认证信息，而无需硬编码 Token。

如果要修改一个地方？ 在生产环境中不要直接照搬这种本地用户认证，如果在 Google Cloud 上，应考虑使用关联到运行资源的 Service Account，如果在外部环境中，则考虑 Workload Identity Federation 等。

此外，为 ADC 生成的本地文件中也包含认证信息。切勿将其提交到 GitHub。

绝对不能保存到 GitHub 的内容

• credentials.json

• token.json

• OAuth Client Secret

• Service Account JSON key

• private key

• Access Token

• Refresh Token

• 真实的账号 ID 或电子邮箱地址

在示例代码中，请使用诸如 YOUR_PROJECT_ID、YOUR_PROPERTY_ID 这样的虚构值。

常见误解

OAuth 和 Service Account 哪个更高阶？

它们之间没有优劣之分。主体和用途完全不同。

有了 Service Account 就能实现任何自动化吗？

并非如此。我们需要确认各个 Google API 接受哪种认证方式，以及目标服务侧需要授予哪些权限。在 Google Workspace 等服务中，也有其专属的授权规则。

制作 JSON key 是最简单的方法吗？

即使在可以创建的情况下，长期密钥也存在泄露风险。如果在 Google Cloud 上，应优先考虑 attached service account，如果在外部环境中，则优先考虑 Workload Identity Federation 等能够减少长期密钥的架构。

费用、账号与 Project

由于费用和提供条件可能会发生变化，请务必在基准日时核实所使用的各个 API 的计费页面。

归根结底这到底是一种什么样的机制？

OAuth 2.0 和 Service Account 是在安全使用 Google API 时，决定“以谁的身份进行访问”的重要组件。

• 由用户授权应用使用其个人数据 → OAuth 2.0

• 由服务器或批处理程序以自身的身份运行 → Service Account

首先理清这一点，之后遇到 Scope、Access Token、IAM、ADC 等后续出现的词汇时，也能连贯地理解了。

官方信息与一手资料

• Google Identity — Using OAuth 2.0 for Web Server Applications

• Google Cloud — Service accounts overview

• Google Cloud — Authentication for Google Cloud APIs and services

• Google Cloud — Application Default Credentials

• Google Cloud — Set up Application Default Credentials

Papanda TRY：直观对比 OAuth Scope

将其作为 Daily Code 的候选内容：在浏览器卡片中左右对比虚构的 read-only scope 与 write scope，可视化展示允许的操作增加时权限范围也会扩大的特性。不使用真实的 client secret 或 token，以此练习选择最小权限。

归根结底这到底是一个什么样的服务？

“OAuth 2.0 和 Service Account 有什么区别？理清 Google API 认证”是一个只要掌握本文梳理的角色、使用场景和注意事项，并在查阅官方一手资料的同时进行小规模尝试，就能轻松理解的 Google 服务。