将 Google 帐号关联至 OAuth

账号使用行业标准 OAuth 2.0 隐式授权代码 流程进行关联。

您的服务必须支持符合 OAuth 2.0 标准的 授权令牌交换 端点。

隐式 流程中,Google 会在用户的浏览器中打开您的授权端点。成功登录后,您会向 Google 返回长期有效的访问令牌。此访问令牌现在包含在 Google 发送的每个请求中。

授权码 流程中,您需要两个端点:

  • 授权 端点,用于向尚未登录的用户显示登录界面。授权端点还会创建一个短期有效的授权代码,以记录用户对所请求访问权限的同意情况。

  • 令牌交换 端点,负责两种类型的交换:

    1. 将授权代码交换为长期有效的刷新令牌和短期有效的访问令牌。当用户完成账号关联流程时,会发生此交换。
    2. 将长期有效的刷新令牌交换为短期有效的访问令牌。 当 Google 需要新的访问令牌(因为其拥有的访问令牌已过期)时,会发生此交换。

选择 OAuth 2.0 流程

虽然 隐式 流程的实现方式较为简单,但 Google 建议通过隐式流程颁发的访问令牌永不过期。这是因为,如果令牌通过隐式流程过期,用户就必须再次关联其账号。如果您出于安全原因需要令牌过期,我们强烈建议您改用 授权码 流程。

设计准则

本部分介绍了您为 OAuth 关联流程托管的用户界面的设计要求和建议。在 Google 的应用调用后,您的平台会向用户显示“登录 Google”页面和账号关联同意屏幕。用户同意关联账号后,系统会将用户重定向回 Google 的应用。

此图显示了用户将其 Google 账号与您的身份验证系统相关联的步骤。第一个屏幕截图显示了用户从您的平台发起的关联。第二张图片显示了用户登录 Google 的界面,第三张图片显示了用户同意并确认将自己的 Google 账号与您的应用相关联的界面。最后一张屏幕截图显示了 Google 应用中成功关联的用户账号。
图 1.账号关联用户登录 Google 和同意屏幕。

要求

  1. 您必须告知用户,其账号将与 Google 关联, 而不是与 Google Home 或 Google 助理等特定 Google 产品关联。

建议

建议您执行以下操作:

  1. 显示 Google 的隐私权政策。在权限请求页面上添加指向 Google 隐私权政策 的链接。

  2. 要分享的数据。 使用清晰简洁的语言告知用户 Google 需要哪些用户数据以及原因。

  3. 明确的号召性用语。 在同意屏幕上添加明确的号召性用语,例如“同意并关联”。这是因为用户需要了解他们需要与 Google 分享哪些数据才能关联其账号。

  4. 能够取消。 为用户提供返回或取消的方式,以便用户选择不关联。

  5. 清晰的登录流程。 确保用户有清晰的 Google 账号登录方法,例如用于输入用户名和密码的字段,或 使用 Google 账号登录

  6. 能够取消关联。 为用户提供取消关联的机制,例如指向您平台上账号设置的网址。或者,您可以 添加指向 Google 账号的链接,用户 可以在其中管理其关联的账号。

  7. 能够更改用户账号。 为用户提供切换账号的方法。如果用户倾向于拥有多个账号,这一点尤其有用。

    • 如果用户必须关闭权限请求页面才能切换账号,请向 Google 发送可恢复的错误,以便用户可以使用 OAuth 关联隐式 流程登录所需的账号。
  8. 添加您的徽标。 在权限请求页面上显示您的公司徽标。使用您的样式指南放置徽标。如果您还想显示 Google 的徽标,请参阅 徽标和商标

Create the project

To create your project to use account linking:

  1. Go to the Google API Console.
  2. Click Create project.
  3. Enter a name or accept the generated suggestion.
  4. Confirm or edit any remaining fields.
  5. Click Create.

To view your project ID:

  1. Go to the Google API Console.
  2. Find your project in the table on the landing page. The project ID appears in the ID column.

The Google Account Linking process includes a consent screen which tells users the application requesting access to their data, what kind of data they are asking for and the terms that apply. You will need to configure your OAuth consent screen before generating a Google API client ID.

  1. Open the OAuth consent screen page of the Google APIs console.
  2. If prompted, select the project you just created.
  3. On the "OAuth consent screen" page, fill out the form and click the “Save” button.

    Application name: The name of the application asking for consent. The name should accurately reflect your application and be consistent with the application name users see elsewhere. The application name will be shown on the Account Linking consent screen.

    Application logo: An image on the consent screen that will help users recognize your app. The logo is shown on Account linking consent screen and on account settings

    Support email: For users to contact you with questions about their consent.

    Scopes for Google APIs: Scopes allow your application to access your user's private Google data. For the Google Account Linking use case, default scope (email, profile, openid) is sufficient, you don’t need to add any sensitive scopes. It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. Learn more.

    Authorized domains: To protect you and your users, Google only allows applications that authenticate using OAuth to use Authorized Domains. Your applications' links must be hosted on Authorized Domains. Learn more.

    Application Homepage link: Home page for your application. Must be hosted on an Authorized Domain.

    Application Privacy Policy link: Shown on Google Account Linking consent screen. Must be hosted on an Authorized Domain.

    Application Terms of Service link (Optional): Must be hosted on an Authorized Domain.

    Figure 1. Google Account Linking Consent Screen for a fictitious Application, Tunery

  4. Check "Verification Status", if your application needs verification then click the "Submit For Verification" button to submit your application for verification. Refer to OAuth verification requirements for details.

实现 OAuth 服务器

n

为了支持 OAuth 2.0 隐式流程,您的服务通过 HTTPS 提供授权端点。此端点负责身份验证和征得用户同意以获取数据访问权限。授权端点会向尚未登录的用户显示登录界面,并记录用户对所请求访问权限的同意情况。

当 Google 应用需要调用您服务的某个已获授权的 API 时,Google 会使用此端点来征得用户同意,以便代表用户调用这些 API。

Google 账号关联:OAuth 隐式授权流程

以下序列图详细说明了用户、Google 和您服务的端点之间的互动。

用户 Google 应用/ 浏览器 您的身份验证 端点 1. 用户发起关联 2. 重定向到身份验证端点 (GET) client_id、redirect_uri、state、scope 3. 显示登录和意见征求界面 4. 用户进行身份验证并授予同意权限 5. 使用令牌重定向回 Google (GET) access_token、state 6. 存储用户令牌 7. 访问用户资源
图 1. Google 账号关联的 OAuth 2.0 隐式流程中的事件序列。

角色和职责

下表定义了 Google 账号关联 (GAL) OAuth 隐式流程中各个参与者的角色和职责。请注意,在 GAL 中,Google 充当 OAuth 客户端,而您的服务充当身份/服务提供方

执行者 / 组件 GAL 角色 职责
Google 应用 / 服务器 OAuth 客户端 启动流程,使用浏览器重定向接收访问令牌,并安全地存储该令牌以访问服务的 API。
您的授权端点 授权服务器 对用户进行身份验证,征得用户同意,并直接向 Google 签发长期有效的访问令牌。
Google 重定向 URI 回调端点 从授权服务接收用户重定向,其中包含网址 fragment 中的 access_tokenstate 值。

由 Google 发起的典型 OAuth 2.0 隐式流程会话具有以下流程:

  1. Google 会在用户的浏览器中打开您的授权端点。用户登录(如果尚未登录),并授予 Google 权限以通过您的 API 访问其数据(如果尚未授予权限)。
  2. 您的服务会创建访问令牌并将其返回给 Google。为此,请将用户的浏览器重定向回 Google,并将访问令牌附加到请求中。
  3. Google 会调用您服务的 API,并在每个请求中附加访问令牌。您的服务会验证该访问令牌是否授予了 Google 访问相应 API 的授权,然后完成 API 调用。

处理授权请求

当 Google 应用需要使用 OAuth 2.0 隐式流程执行账号关联时,Google 会将用户发送到您的授权端点,并发送包含以下参数的请求:

授权端点参数
client_id 您分配给 Google 的客户 ID。
redirect_uri 您将对此请求的响应发送到的网址。
state 一种簿记值,在重定向 URI 中原封不动地传递回 Google。
response_type 要在响应中返回的值的类型。对于 OAuth 2.0 隐式流程,响应类型始终为 token
user_locale Google 账号语言设置(采用 RFC5646 格式),用于以用户的首选语言本地化您的内容。

例如,如果您的授权端点位于 https://myservice.example.com/auth,则请求可能如下所示:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&response_type=token&user_locale=LOCALE

如需让授权端点处理登录请求,请执行以下步骤:

  1. 验证 client_idredirect_uri 值,以防止向意外或配置错误的客户端应用授予访问权限:

    • 确认 client_id 与您分配给 Google 的客户端 ID 相一致。
    • 确认 redirect_uri 参数指定的网址具有以下格式:
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
      https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
      
  2. 检查用户是否已登录您的服务。如果用户未登录,请完成服务的登录或注册流程。

  3. 生成供 Google 用于访问您的 API 的访问令牌。访问令牌可以是任何字符串值,但必须唯一表示用户和令牌所针对的客户端,并且不得是可猜测的值。

  4. 发送 HTTP 响应,将用户的浏览器重定向到 redirect_uri 参数指定的网址。在网址片段中包含以下所有参数:

    • access_token:您刚刚生成的访问令牌
    • token_type:字符串 bearer
    • state:原始请求中的未修改状态值

    以下是生成的网址示例:

    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING

Google 的 OAuth 2.0 重定向处理程序会接收访问令牌,并确认 state 值未发生变化。在 Google 为您的服务获取访问令牌后,Google 会将该令牌附加到后续对您的服务 API 的调用中。

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

userinfo endpoint request headers
Authorization header The access token of type Bearer.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

  1. Extract access token from the Authorization header and return information for the user associated with the access token.
  2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:
    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: error="invalid_token",
    error_description="The Access Token expired"
    
    If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.
  3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

    {
    "sub": "USER_UUID",
    "email": "EMAIL_ADDRESS",
    "given_name": "FIRST_NAME",
    "family_name": "LAST_NAME",
    "name": "FULL_NAME",
    "picture": "PROFILE_PICTURE",
    }
    If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

    userinfo endpoint response
    sub A unique ID that identifies the user in your system.
    email Email address of the user.
    given_name Optional: First name of the user.
    family_name Optional: Last name of the user.
    name Optional: Full name of the user.
    picture Optional: Profile picture of the user.

验证您的实现

您可以使用 OAuth 2.0 Playground 工具验证您的实现。

在该工具中,执行以下步骤:

  1. 点击配置 以打开“OAuth 2.0 配置”窗口。
  2. OAuth flow(OAuth 流程)字段中,选择 Client-side(客户端)。
  3. OAuth Endpoints 字段中,选择 Custom
  4. 在相应字段中指定您的 OAuth 2.0 端点以及您分配给 Google 的客户端 ID。
  5. 第 1 步部分中,请勿选择任何 Google 范围。请将此字段留空,或输入适用于您服务器的范围(如果您不使用 OAuth 范围,则输入任意字符串)。完成后,点击 Authorize APIs
  6. 第 2 步第 3 步部分中,完成 OAuth 2.0 流程,并验证每个步骤是否按预期运行。

您可以使用 Google 账号关联演示工具验证您的实现。

在该工具中,执行以下步骤:

  1. 点击使用 Google 账号登录按钮。
  2. 选择您要关联的账号。
  3. 输入服务 ID。
  4. (可选)输入您将请求访问的一个或多个范围。
  5. 点击开始演示
  6. 当系统提示时,请确认您可以同意或拒绝关联请求。
  7. 确认您已重定向到相应平台。