本指南可帮助您选择是使用 Google Identity 服务库进行用户授权，还是实现自己的 JavaScript 库。它可帮助您确定哪种 OAuth 2.0 授权流程最适合您的 Web 应用。
在阅读本指南之前，我们假设您已熟悉概览和用户授权的运作方式指南中所述的术语和概念。
GIS 库在用户设备上的这些受支持的浏览器中运行。它不适用于 Node.js 等服务器端 JavaScript 框架，请改用 Google 的 Node.js 客户端库。
本指南仅涵盖授权和数据共享主题。它不审核用户身份验证，而是请参阅使用 Google 账号登录和从 Google 登录迁移指南，了解用户注册和登录。
确定 GIS 库是否适合您
您必须选择是使用 Google 的库，还是创建最符合您需求的库。功能概览：
- Google 的 Identity 服务 JavaScript 库实现了以下功能：
- 基于对话框的同意流程，可最大限度地减少重定向，让用户在整个授权过程中留在您的网站上。
- 安全功能，例如跨站请求伪造 (CRSF)。
- 用于请求各个范围并确认用户同意情况的辅助方法。
- 人性化的错误处理和文档链接，供工程师在开发期间使用，也供网站访问者在稍后使用。
- 在不使用身份服务库的情况下进行实现时，您需要负责：
- 使用 Google 的 OAuth 2.0 端点管理请求和响应，包括重定向。
- 优化用户体验。
- 实现安全功能以验证请求、响应并防止 CSRF。
- 用于确认用户已针对任何请求的范围授予同意权限的方法。
- 管理 OAuth 2.0 错误代码、创建人类可读的消息，以及指向用户帮助的链接。
总而言之，Google 提供 GIS 库，可帮助您快速安全地实现 OAuth 2.0 客户端，并优化用户的授权体验。
选择授权流程
无论您决定使用 Google Identity Services JavaScript 库还是创建自己的库，都需要选择两种 OAuth 2.0 授权流程之一：隐式或授权代码。
这两种流程都会生成一个访问令牌，可用于调用 Google API。
这两个流程之间的主要区别如下：
- 用户操作次数，
- 您的应用是否会在用户不在场的情况下调用 Google API，
- 如果需要后端平台来托管端点并存储各个用户账号的每个用户刷新令牌，并且
- 更高或更低的用户安全级别。
在比较流程和评估安全要求时，需要考虑的一个因素是，用户安全级别会因您选择的范围而异。例如，以只读方式查看日历邀请的风险可能低于使用读写范围来编辑云端硬盘中的文件。
OAuth 2.0 流程比较
| 隐式流程 | 授权代码流程 | |
| 需要征得用户同意 | 对于每个令牌请求，包括替换过期令牌。 | 仅适用于第一个令牌请求。 |
| 用户必须在场 | 是 | 否，支持离线使用。 |
| 用户安全 | 最少 | 大多数都具有客户端身份验证功能，可避免浏览器内令牌处理风险。 |
| 已签发访问令牌 | 是 | 是 |
| 已签发刷新令牌 | 否 | 是 |
| 需要使用受支持的浏览器 | 是 | 是 |
| 用于调用 Google API 的访问令牌 | 仅来自用户浏览器中运行的 Web 应用。 | 来自后端平台上运行的服务器，或来自用户浏览器中运行的 Web 应用。 |
| 需要后端平台 | 否 | 是，适用于端点托管和存储。 |
| 需要安全存储 | 否 | 是，用于存储刷新令牌。 |
| 需要托管授权代码端点 | 否 | 是，以便接收来自 Google 的授权代码。 |
| 访问令牌过期行为 | 需要用户手势（例如按按钮或点击链接）才能请求并获取新的有效访问令牌。 | 在用户发出初始请求后，您的平台会交换存储的刷新令牌，以获取调用 Google API 所需的新有效访问令牌。 |