跨客户端身份

开发者构建软件时,通常包括在网络服务器上运行的模块、在浏览器中运行的其他模块,以及其他作为原生移动应用运行的模块。开发者和使用其软件的人通常认为所有这些模块都是单个应用的一部分。

Google 的 OAuth 2.0 实现支持这种世界视角。如需使用任何基于 OAuth2.0 的服务,您必须在 Google API Console中设置软件。 API Console 中的组织单元是一个“项目”,可对应于一个多组件应用。对于每个项目,您可以提供品牌信息,并且必须指定该应用将访问的 API。多组件应用的每个组件都由一个客户端 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 应用)再次请求该作用域的访问权限。