开发者构建软件时，通常会包含在 Web 服务器上运行的模块、在浏览器中运行的其他模块，以及作为原生移动应用运行的其他模块。开发者和使用其软件的用户通常会将所有这些模块视为单个应用的一部分。
Google 的 OAuth 2.0 实现支持这种世界观。如需使用任何基于 OAuth2.0 的服务，您必须在 Google API Console中设置软件。 API Console 中的组织单元是“项目”，可以对应于多组件应用。对于每个项目，您都可以提供品牌信息，并且必须指定应用将访问哪些 API。多组件应用的每个组件都由客户端 ID 进行标识，该 ID 是 API Console中生成的唯一字符串。
跨客户端授权目标
当应用使用 OAuth 2.0 进行授权时，应用会代表用户请求 OAuth 2.0 访问令牌以访问资源，该资源由应用通过一个或多个范围字符串进行标识。通常情况下，系统会要求用户批准相应访问权限。
当用户授予对您应用的特定范围的访问权限时，用户会看到用户意见征求界面，其中包含您在 Google API Console中设置的项目级产品品牌信息。因此，Google 认为，当用户向项目中的任何客户端 ID 授予对特定范围的访问权限时，该授予表示用户对该范围的整个应用的信任。
这样一来，只要应用的组件可以通过 Google 的授权基础架构（目前包括 Web 应用、Android 应用、Chrome 应用、iOS 应用、原生桌面应用和限制输入设备）可靠地进行身份验证，系统就不会针对同一逻辑应用重复提示用户批准对任何资源的访问权限。
跨客户端访问令牌
软件可以通过多种方式获取 OAuth 2.0 访问令牌，具体取决于代码运行的平台。如需了解详情，请参阅使用 OAuth 2.0 访问 Google API。通常，授予访问令牌时需要用户批准。
幸运的是，Google 授权基础架构在评估是否授权同一项目中的其他客户端 ID 时，可以使用有关给定项目中客户端 ID 的用户审批的信息。
其结果是，如果 Android 应用为特定范围请求访问令牌，而发出请求的用户已经针对同一范围批准同一项目中的 Web 应用，则系统不会再次要求用户批准。这可双向使用：如果 Android 应用已授予对某个范围的访问权限，则不会再向同一项目中的其他客户端（例如 Web 应用）再次请求该访问权限。