アカウントは、業界標準の OAuth 2.0 のインプリシット フローと認可コードフローを使用してリンクされます。
サービスは、OAuth 2.0 準拠の認可エンドポイントとトークン交換エンドポイントをサポートする必要があります。
在 隐式 流程中,Google 会在用户的浏览器中打开您的授权端点。成功登录后,您会向 Google 返回长期有效的访问令牌。此访问令牌现在包含在 Google 发送的每个请求中。
在 授权代码 流程中,您需要两个端点:
授权 端点,用于向尚未登录的用户显示登录界面。授权端点还会创建一个短期有效的授权代码,以记录用户对所请求访问权限的同意情况。
令牌交换 端点,负责两种类型的交换:
- 将授权代码交换为长期有效的刷新令牌和短期有效的访问令牌。当用户完成账号关联流程时,会发生此交换。
- 将长期有效的刷新令牌交换为短期有效的访问令牌。 当 Google 需要新的访问令牌(因为其拥有的访问令牌已过期)时,会发生此交换。
选择 OAuth 2.0 流程
虽然 隐式 流程的实现较为简单,但 Google 建议通过隐式流程颁发的访问令牌永不过期。这是因为,如果令牌通过隐式流程过期,用户就必须再次关联其账号。如果您出于安全原因需要令牌过期,我们强烈建议您改用 授权代码 流程。
设计准则
本部分介绍了您为 OAuth 关联流程托管的用户界面的设计要求和建议。在 Google 的应用调用后,您的平台会向用户显示“登录 Google”页面和账号关联同意屏幕。用户同意关联账号后,系统会将用户重定向回 Google 的应用。
要求
- 您必须说明,用户的账号将与 Google 关联, 而不是与 Google Home 或 Google 助理等特定 Google 产品关联。
建议
建议您执行以下操作:
显示 Google 的隐私权政策。在权限请求页面上添加指向 Google 的隐私权政策 的链接。
要共享的数据。 使用清晰简洁的语言告知用户 Google 需要哪些数据及其原因。
明确的号召性用语。 在同意屏幕上添加明确的号召性用语,例如“同意并关联”。 这是因为用户需要了解他们需要与 Google 共享哪些数据才能关联其账号。
能够取消。 为用户提供返回或取消的方式(如果他们选择不关联)。
清晰的登录流程。 确保用户有清晰的 Google 账号登录方法,例如用户名和密码字段,或 “使用 Google 账号登录”。
能够取消关联。 为用户提供取消关联的机制,例如指向您平台上账号设置的网址。或者,您可以 添加指向 Google 账号的链接,用户 可以在其中管理其关联的账号。
能够更改用户账号。 为用户提供切换账号的方法。如果用户倾向于拥有多个账号,这一点尤其有用。
- 如果用户必须关闭权限请求页面才能切换账号,请向 Google 发送可恢复的错误,以便用户可以使用 OAuth 关联 和 隐式 流程登录所选账号。
添加您的徽标。 在权限请求页面上显示您的公司徽标。请按照您的样式指南放置徽标。如果您想要或需要 同时显示 Google 的徽标,请参阅 徽标和商标。
プロジェクトを作成する
アカウント リンクを使用するプロジェクトを作成するには:
- Google API コンソールに移動します。
- [プロジェクトの作成] をクリックします。
- 名前を入力するか、生成された候補を受け入れます。
- 残りのフィールドを確認または編集します。
- [作成] をクリックします。
プロジェクト ID を表示するには:
- Google API コンソールに移動します。
- ランディング ページの表でプロジェクトを探します。プロジェクト ID は [ID] 列に表示されます。
OAuth 同意画面を構成する
Google アカウントのリンク プロセスには同意画面が含まれています。この画面では、データへのアクセスをリクエストしているアプリケーション、リクエストしているデータの種類、適用される規約がユーザーに通知されます。Google API クライアント ID を生成する前に、OAuth 同意画面を構成する必要があります。
- Google API コンソールの OAuth 同意画面 ページを開きます。
- プロンプトが表示されたら、作成したプロジェクトを選択します。
[OAuth 同意画面] ページでフォームに入力し、[保存] ボタンをクリックします。
アプリケーション名: 同意を求めるアプリケーションの名前。名前はアプリケーションを正確に反映し、ユーザーが他の場所で見るアプリケーション名と一致している必要があります。アプリケーション名は、アカウント リンクの同意画面に表示されます。
アプリケーション ロゴ: 同意画面に表示される画像で、ユーザーがアプリを認識しやすくなります。ロゴは、アカウント リンクの同意画面とアカウント設定に表示されます。
サポートメール: 同意に関して問い合わせる際に使用します。
Google API のスコープ: スコープを使用すると、アプリケーションはユーザーの非公開の Google データにアクセスできます。Google アカウントのリンクのユースケースでは、デフォルトのスコープ(email、profile、openid)で十分です。機密性の高いスコープを追加する必要はありません。一般的に、スコープは事前にリクエストするのではなく、アクセスが必要になったときに段階的にリクエストすることが効果的な手法です。詳細
承認済みドメイン: デベロッパーとユーザーを保護するために、Google では、OAuth を使用して認証するアプリケーションのみに承認済みドメインの使用を許可しています。アプリケーションのリンクは、承認済みドメインでホストする必要があります。詳細
アプリケーションのホームページへのリンク: アプリケーションのホームページ。承認済みドメインでホストする必要があります。
アプリケーションのプライバシー ポリシーへのリンク: Google アカウント リンクの同意画面に表示されます。承認済みドメインでホストする必要があります。
アプリケーションの利用規約へのリンク(省略可): 承認済みドメインでホストする必要があります。
図 1. 架空のアプリケーション Tunery の Google アカウントのリンクの同意画面
[検証ステータス] を確認します。アプリケーションの検証が必要な場合は、[検証のために送信] ボタンを**クリック**して、検証を受けるためにアプリケーションを送信します。詳しくは、OAuth の検証要件をご覧ください。
OAuth サーバーを実装する
n
为了支持 OAuth 2.0 隐式流程,您的服务通过 HTTPS 提供授权端点。此端点负责身份验证和征得用户同意以获取数据访问权限。授权端点会向尚未登录的用户显示登录界面,并记录用户对所请求访问权限的同意情况。
当 Google 应用需要调用您服务的某个已获授权的 API 时,Google 会使用此端点来征得用户同意,以便代表用户调用这些 API。
Google 账号关联:OAuth 隐式授权流程
以下序列图详细说明了用户、Google 和您服务的端点之间的互动。
角色和职责
下表定义了 Google 账号关联 (GAL) OAuth 隐式流程中各个参与者的角色和职责。请注意,在 GAL 中,Google 充当 OAuth 客户端,而您的服务充当身份/服务提供方。
| 执行者 / 组件 | GAL 角色 | 职责 |
|---|---|---|
| Google 应用 / 服务器 | OAuth 客户端 | 启动流程,使用浏览器重定向接收访问令牌,并安全地存储该令牌以访问服务的 API。 |
| 您的授权端点 | 授权服务器 | 对用户进行身份验证,征得用户同意,并直接向 Google 签发长期有效的访问令牌。 |
| Google 重定向 URI | 回调端点 | 从授权服务接收用户重定向,其中包含网址 fragment 中的 access_token 和 state 值。 |
由 Google 发起的典型 OAuth 2.0 隐式流程会话具有以下流程:
- Google 会在用户的浏览器中打开您的授权端点。用户登录(如果尚未登录),并授予 Google 权限以通过您的 API 访问其数据(如果尚未授予权限)。
- 您的服务会创建访问令牌并将其返回给 Google。为此,请将用户的浏览器重定向回 Google,并将访问令牌附加到请求中。
- 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
如需让授权端点处理登录请求,请执行以下步骤:
验证
client_id和redirect_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
- 确认
检查用户是否已登录您的服务。如果用户未登录,请完成服务的登录或注册流程。
生成供 Google 用于访问您的 API 的访问令牌。访问令牌可以是任何字符串值,但必须唯一表示用户和令牌所针对的客户端,并且不得是可猜测的值。
发送 HTTP 响应,将用户的浏览器重定向到
redirect_uri参数指定的网址。在网址片段中包含以下所有参数:access_token:您刚刚生成的访问令牌token_type:字符串bearerstate:原始请求中的未修改状态值
以下是生成的网址示例:
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 的调用中。
处理 userinfo 请求
userinfo 端点是受 OAuth 2.0 保护的资源,会返回关联用户的声明。实现和托管 userinfo 端点是可选的,但以下用例除外:
从您的令牌端点成功检索到访问令牌后,Google 会向您的 userinfo 端点发送请求,以检索关联用户的基本个人资料信息。
| userinfo 端点请求标头 | |
|---|---|
Authorization header |
Bearer 类型的访问令牌。 |
例如,如果您的 userinfo 端点可通过
https://myservice.example.com/userinfo 时,请求可能如下所示:
GET /userinfo HTTP/1.1 Host: myservice.example.com Authorization: Bearer ACCESS_TOKEN
为了让 userinfo 端点能够处理请求,请执行以下步骤:
- 从 Authorization 标头中提取访问令牌,并返回与访问令牌相关联的用户的信息。
- 如果访问令牌无效,则使用
WWW-Authenticate响应标头返回 HTTP 401 Unauthorized 错误。下面是一个 userinfo 错误响应示例: 如果在关联过程中返回 401 未经授权错误或任何其他失败的错误响应,该错误将无法恢复,检索到的令牌将被舍弃,并且用户必须重新开始关联流程。HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
如果访问令牌有效,则返回 HTTPS 正文中包含以下 JSON 对象的 HTTP 200 响应 回答:
如果您的 userinfo 端点返回 HTTP 200 成功响应,则系统会针对用户的 Google 账号注册检索到的令牌和声明。{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }userinfo 端点响应 sub系统中用于识别用户的唯一 ID。 email用户的电子邮件地址。 given_name可选:用户的名字。 family_name可选:用户的姓氏。 name可选:用户的全名。 picture可选:用户的个人资料照片。
実装の検証
OAuth 2.0 Playground ツールを使用して、実装を検証できます。
このツールで、次の手順を行います。
- [構成] 設定をクリックして、[OAuth 2.0 構成] ウィンドウを開きます。
- [OAuth flow] フィールドで、[クライアントサイド] を選択します。
- [OAuth Endpoints] フィールドで、[Custom] を選択します。
- 対応するフィールドに、OAuth 2.0 エンドポイントと Google に割り当てたクライアント ID を指定します。
- [Step 1] セクションで、Google スコープを選択しないでください。代わりに、このフィールドを空白のままにするか、サーバーで有効なスコープを入力します(OAuth スコープを使用しない場合は任意の文字列を入力します)。完了したら、[Authorize APIs] をクリックします。
- [Step 2] セクションと [Step 3] セクションで、OAuth 2.0 フローを確認し、各ステップが意図したとおりに動作することを確認します。
Google アカウント リンク デモツールを使用して、実装を検証できます。
このツールで、次の手順を行います。
- [Google でログイン] ボタンをクリックします。
- リンクするアカウントを選択します。
- サービス ID を入力します。
- 必要に応じて、アクセスをリクエストするスコープを 1 つ以上入力します。
- [Start Demo] をクリックします。
- 確認のメッセージが表示されたら、リンク リクエストに同意または拒否できることを確認します。
- プラットフォームにリダイレクトされることを確認します。