开发者构建软件时，通常会包含在 Web 服务器上运行的模块、在浏览器中运行的其他模块，以及作为 Android 或 iOS 移动应用运行的其他模块。开发者和使用其软件的人员通常会将所有这些模块视为单个应用的一部分。
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 应用）不会再次要求获得该权限。