OAuth による Google アカウントのリンク

アカウントは、業界標準の OAuth 2.0 インプリシット フローと認可コードフローを使用してリンクされます。サービスは、OAuth 2.0 準拠の認可エンドポイントとトークン交換エンドポイントをサポートする必要があります。

暗黙的フローでは、Google がデベロッパーのブラウザで認可エンドポイントを開きます。ログインに成功したら、認可エンドポイントから長期のアクセス トークンを Google に返します。このアクセス トークンは、Google から送信されるすべてのリクエストに含まれます。

認証コードフローでは、次の 2 つのエンドポイントが必要になります。

• 認可エンドポイント。ログインしていないユーザーにログイン用の UI を表示します。認可エンドポイントは、リクエストされたアクセスに対するユーザーの同意を記録するために、有効期間の短い認可コードも作成します。

• トークン交換エンドポイント。次の 2 種類の交換を行います。

  1. 長期の更新トークンと短期のアクセス トークンの認可コードを交換します。この処理は、ユーザーがアカウントのリンクフローを行ったときに発生します。
  2. 長期の更新トークンを短期のアクセス トークンと交換します。この処理は、トークンが期限切れになり、新しいアクセス トークンが必要になった場合に発生します。

OAuth 2.0 フローを選択する

暗黙的フローの実装は簡単ですが、暗黙的フローによって発行されたアクセス トークンには有効期限を設定しないことをおすすめします。これは、暗黙的フローでトークンが期限切れになると、ユーザーがアカウントを再度リンクしなければならないためです。セキュリティ上の理由からトークンに有効期限を設定する必要がある場合は、代わりに認可コードフローを使用することを強くおすすめします。

設計ガイドライン

このセクションでは、OAuth リンクフロー用にホストするユーザー画面の設計要件と推奨事項について説明します。Google のアプリから呼び出されると、プラットフォームはユーザーに Google にログインするページとアカウントのリンクに関する同意画面を表示します。アカウントのリンクに同意すると、ユーザーは Google のアプリに戻されます。

要件

1. ユーザーのアカウントは、Google Home や Google アシスタントなどの特定の Google プロダクトではなく、Google にリンクされることを伝える必要があります。

推奨事項

次のことをおすすめします。

1. Google のプライバシー ポリシーを表示する。同意画面に Google のプライバシー ポリシーへのリンクを含めます。

2. 共有するデータ。明確で簡潔な表現を使用して、Google に必要なデータとその理由をユーザーに伝えます。

3. 行動を促す明確なフレーズ同意画面に「同意してリンク」など、わかりやすい行動を促すフレーズを表示します。これは、アカウントをリンクするために Google と共有する必要があるデータをユーザーが理解する必要があるためです。

4. キャンセルできること。ユーザーがリンクしないことを選択した場合に、ユーザーが戻るまたはキャンセルできる方法を提供します。

5. ログイン プロセスを明確にする。ユーザーが Google アカウントにログインするための明確な方法（ユーザー名とパスワードのフィールド、Google でログインなど）があることを確認します。

6. リンクを解除できること。ユーザーがリンクを解除するためのメカニズム（プラットフォームのアカウント設定への URL など）を提供します。または、ユーザーがリンクされたアカウントを管理できる Google アカウントへのリンクを含めることもできます。

7. ユーザー アカウントを変更する機能。ユーザーがアカウントを切り替える方法を提案します。これは、ユーザーが複数のアカウントを持っている場合に特に便利です。

   • ユーザーがアカウントを切り替えるために同意画面を閉じる必要がある場合は、回復可能なエラーを Google に送信して、ユーザーが OAuth リンクと暗黙的フローを使用して目的のアカウントにログインできるようにします。

8. ロゴを含めます。同意画面に会社のロゴを表示します。 スタイル ガイドラインに沿ってロゴを配置します。Google のロゴも表示する場合は、ロゴと商標をご覧ください。

プロジェクトを作成する

アカウントのリンクを使用するプロジェクトを作成するには:

OAuth 同意画面を構成する

Google アカウントのリンクのプロセスには、データへのアクセスをリクエストするアプリがユーザーに対し、どのようなデータを要求し、適用される規約があるかを伝える同意画面が含まれます。Google API クライアント ID を生成する前に、OAuth 同意画面を構成する必要があります。

1. Google API コンソールの OAuth 同意画面ページを開きます。
2. プロンプトが表示されたら、作成したプロジェクトを選択します。

3. [OAuth 同意画面] ページで、フォームに記入して [保存] ボタンをクリックします。

   アプリケーション名: 同意を求めるアプリの名前。名前は、アプリを正確に反映し、ユーザーが他の場所で目にするアプリ名と一貫している必要があります。アプリケーション名は、アカウントのリンクの同意画面に表示されます。

   アプリのロゴ: ユーザーがアプリを認識できるように、同意画面に表示する画像。ロゴは、アカウントのリンクに関する同意画面とアカウント設定に表示されます。

   サポートメール: ユーザーが同意について問い合わせる際に使用するメールです。

   Google API のスコープ: スコープを使用すると、アプリケーションがユーザーの非公開の Google データにアクセスできるようになります。Google アカウントのリンクのユースケースでは、デフォルトのスコープ（email、profile、openid）で十分であり、機密性の高いスコープを追加する必要はありません。通常、事前にではなく、アクセスが必要になったときにスコープを段階的にリクエストすることをおすすめします。詳細

   承認済みドメイン: デベロッパーとユーザーを保護するため、Google では OAuth を使用して認証するアプリケーションのみに承認済みドメインの使用を許可しています。アプリのリンクは、承認済みドメインでホストする必要があります。詳細

   アプリケーションのホームページへのリンク: アプリケーションのホームページ。承認済みドメインでホストされている必要があります。

   アプリケーションのプライバシー ポリシーのリンク: Google アカウントのリンクの同意画面に表示されます。承認済みドメインでホストされている必要があります。

   アプリケーションの利用規約へのリンク（省略可）: 承認済みドメインでホストされている必要があります。

   

   図 1. 架空のアプリ「Tunery」の Google アカウントのリンクに関する同意画面

4. [確認ステータス] を確認します。アプリの確認が必要な場合は、[確認のために送信] ボタンをクリックして確認のためにアプリを送信します。詳しくは、OAuth 検証の要件をご覧ください。

OAuth サーバーを実装する

授权代码流程的 OAuth 2.0 服务器实现包括 两个端点，您的服务会通过 HTTPS 提供这两个端点。第一个端点 是授权端点，负责查找或获取 就数据访问征求用户意见。授权端点会提供一个 尚未登录的用户的登录界面，并记录同意情况 请求的访问权限。第二个端点是令牌交换端点， 用于获取加密字符串（称为令牌），以授权用户 访问您的服务。

当 Google 应用需要调用您的某个服务的 API 时，Google 会使用 将这些端点组合在一起，以获取用户调用这些 API 的权限 。

由 Google 发起的 OAuth 2.0 授权代码流程会话包含 以下流程：

1. Google 会在用户的浏览器中打开您的授权端点。如果流 在用户通过纯语音设备上针对某个 Action 启动，Google 会将 将代码执行到手机上
2. 用户登录（如果尚未登录），并授予 Google 以下权限： 访问您的 API 访问其数据（如果尚未授权）。
3. 您的服务会创建授权代码并将其返回给 Google。待办事项 因此，请使用授权代码将用户的浏览器重定向回 Google。 附件。
4. Google 会将授权代码发送到您的令牌交换端点， 验证代码的真实性并返回访问令牌和 刷新令牌。访问令牌是一个短期有效的令牌 作为访问 API 的凭据。刷新令牌长期有效 Google 可以存储该令牌，以便在用户首次访问该令牌时， 过期。
5. 在用户完成账号关联流程后， 从 Google 发送的请求中包含访问令牌。

处理授权请求

需要使用 OAuth 2.0 授权代码执行账号关联的情况 流程中，Google 会通过请求将用户发送到您的授权端点 包含以下参数：

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

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

为了让授权端点能够处理登录请求，请执行以下操作 步骤：

1. 验证 client_id 是否与您分配给 Google 的 Client ID 匹配，以及 redirect_uri 与 Google 为您的服务提供的重定向网址是否匹配。这些检查对于防止 访问意外或配置错误的客户端应用。如果你支持多种 OAuth 2.0 流程，还应确认 response_type 是否为 code。
2. 检查用户是否已登录您的服务。如果用户没有登录， 完成服务的登录或注册流程。
3. 生成授权代码，以供 Google 用于访问您的 API。 授权代码可以是任何字符串值，但它必须是唯一的 代表用户、令牌对应的客户端以及代码的有效期 而且不可猜测出来。您通常需要进行授权 会在大约 10 分钟后过期。
4. 确认 redirect_uri 参数指定的网址包含 以下表单：

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. 将用户的浏览器重定向到 redirect_uri 参数。添加您在 以及您在重定向时返回未经修改的原始状态值 方法是附加 code 和 state 参数。以下是 生成的网址示例：

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

处理令牌交换请求

您的服务的令牌交换端点负责处理两种令牌 广告交易平台：

• 交换访问令牌和刷新令牌的授权代码
• 用刷新令牌换取访问令牌

令牌交换请求包含以下参数：

交换访问令牌和刷新令牌的授权代码

用户登录且您的授权端点返回一个短期有效的 授权代码发送给 Google，Google 会向您的令牌交换发送请求 端点使用授权代码交换访问令牌和刷新 令牌。

对于这些请求，grant_type 的值为 authorization_code， 的 code 值是您先前授予的授权代码的值 。以下是发送 访问令牌和刷新令牌的授权代码：

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

要将授权代码交换为访问令牌和刷新令牌，您的 令牌交换端点通过执行以下命令来响应 POST 请求： 步骤：

1. 验证 client_id 是否将请求来源标识为已获授权的请求来源 来源，并且 client_secret 与预期值匹配。
2. 请确认授权代码有效且未过期， 请求中指定的客户端 ID 与 授权代码。
3. 确认 redirect_uri 参数指定的网址完全相同 初始授权请求中使用的值。
4. 如果您无法验证上述所有条件，则返回 HTTP 正文为 {"error": "invalid_grant"} 的 400 Bad Request 错误。
5. 否则，使用授权代码中的用户 ID 来生成刷新 令牌和访问令牌。这些标记可以是任何字符串值， 必须唯一地代表用户和令牌对应的客户端， 不得被猜到对于访问令牌，请记录 令牌，通常是在您发出令牌一个小时后。 刷新令牌不会过期。
6. 在 HTTPS 响应的正文中返回以下 JSON 对象：

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

Google 会存储用户的访问令牌和刷新令牌，并存储相关记录 访问令牌的有效期。访问令牌过期后，Google 会使用 刷新令牌，以从令牌交换端点获取新的访问令牌。

用刷新令牌换取访问令牌

访问令牌过期后，Google 会向您的令牌交换发送请求 端点将刷新令牌交换为新的访问令牌。

对于这些请求，grant_type 的值为 refresh_token，值 “refresh_token”是您之前授予的刷新令牌的值 Google。以下是交换刷新令牌的请求示例 获取访问令牌：

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

如需将刷新令牌交换为访问令牌，令牌交换端点 来响应 POST 请求：

1. 验证 client_id 是否将请求来源标识为 Google，并 client_secret 与预期值一致。
2. 请确认刷新令牌有效，以及在 请求与刷新令牌所关联的客户端 ID 相匹配。
3. 如果您无法验证上述所有条件，则返回 HTTP 400 正文为 {"error": "invalid_grant"} 的 Bad Request 错误。
4. 否则，请使用刷新令牌中的用户 ID 来生成访问权限 令牌。这些标记可以是任何字符串值，但它们必须是唯一的 代表用户和客户端，而不得 猜测。对于访问令牌，请记录令牌的到期时间， 通常在您发出令牌一小时后发送
5. 在 HTTPS 的正文中返回以下 JSON 对象 回答：

   {
   "token_type": "不记名",
   "access_token": "ACCESS_TOKEN",
   “expires_in”：SECONDS_TO_EXPIRATION
   }

userinfo リクエストを処理する

userinfo エンドポイントは、OAuth 2.0 で保護されたリソースで、リンクされたユーザーに関するクレームを返します。userinfo エンドポイントの実装とホストは任意ですが、以下のユースケースを除きます。

• Google One タップによるリンクされたアカウントへのログイン。
• Android TV のスムーズな定期購入。

トークン エンドポイントからアクセス トークンが正常に取得されると、Google は、リンクされたユーザーに関する基本的なプロフィール情報を取得するためのリクエストを userinfo エンドポイントに送信します。

たとえば、userinfo エンドポイントが https://myservice.example.com/userinfo の場合、リクエストは次のようになります。

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

userinfo エンドポイントでリクエストを処理するには、次の手順を行います。

1. Authorization ヘッダーからアクセス トークンを抽出し、そのアクセス トークンに関連付けられたユーザーの情報を返します。
2. アクセス トークンが無効な場合は、WWW-Authenticate レスポンス ヘッダーを使用して HTTP 401 Unauthorized エラーを返します。userinfo エラー レスポンスの例を次に示します。

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   リンク処理中に 401 Unauthorized またはその他の失敗したエラー レスポンスが返された場合、そのエラーは修復不能となり、取得したトークンは破棄されるため、ユーザーはリンク処理をやり直す必要があります。

3. アクセス トークンが有効な場合は、HTTPS の本文に次の JSON オブジェクトを含む HTTP 200 レスポンスを返します。 レスポンス:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }
   

   userinfo エンドポイントが HTTP 200 成功レスポンスを返すと、取得したトークンとクレームがユーザーの Google アカウントに登録されます。

   userinfo エンドポイント レスポンス
   sub	システム内でユーザーを識別する一意の ID。
   email	ユーザーのメールアドレス。
   given_name	省略可: ユーザーの名。
   family_name	省略可: ユーザーの姓。
   name	省略可: ユーザーの氏名。
   picture	省略可: ユーザーのプロフィール写真。

実装の検証

実装を検証するには、OAuth 2.0 Playground ツールを使用します。

ツールで、次の操作を行います。

1. [Configuration] settings をクリックして [OAuth 2.0 Configuration] ウィンドウを開きます。
2. [OAuth flow] フィールドで、[Client-side] を選択します。
3. [OAuth Endpoints]（OAuth エンドポイント）で、[Custom]（カスタム）を選択します。
4. 対応するフィールドに、OAuth 2.0 エンドポイントと Google に割り当てたクライアント ID を指定します。
5. [ステップ 1] セクションで、Google スコープは選択しないでください。代わりに、このフィールドを空白のままにするか、サーバーで有効なスコープを入力します（OAuth スコープを使用しない場合は任意の文字列を入力します）。完了したら、[API を承認] をクリックします。
6. ステップ 2 とステップ 3 のセクションで OAuth 2.0 フローを実行し、各ステップが意図したとおりに機能することを確認します。

実装を検証するには、Google アカウント リンクのデモツールを使用します。

ツールで次の操作を行います。

1. [Google でログイン] ボタンをクリックします。
2. リンクするアカウントを選択します。
3. サービス ID を入力します。
4. 必要に応じて、アクセスをリクエストするスコープを 1 つ以上入力します。
5. [デモを開始] をクリックします。
6. リンク リクエストに同意できることを確認して、リクエストを拒否します。
7. プラットフォームにリダイレクトされることを確認します。