开发者在构建软件时，通常包括在网络服务器上运行的模块、在浏览器中运行的其他模块，以及作为原生移动应用运行的模块。开发者和软件开发者通常都把所有这些模块视为单个应用的一部分。
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 的用户审批信息。
结果是，如果 Android 应用请求特定范围的访问令牌，但请求的用户已授予同一范围内的同一 Web 应用的审批，则系统不会再次请求用户批准。这两种方式都有作用：如果已在 Android 应用中授予某个范围的访问权限，则不会再请求同一项目中的其他客户端（如 Web 应用）的访问权限。