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

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

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

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

認可エンドポイント。ログインしていないユーザーにログイン用の UI を表示します。認可エンドポイントは、リクエストされたアクセスに対するユーザーの同意を記録するために、有効期間の短い認可コードも作成します。
トークン交換エンドポイント。次の 2 種類の交換を行います。
1. 長期の更新トークンと短期のアクセストークンの認可コードを交換します。この処理は、ユーザーがアカウントのリンクフローを行ったときに発生します。
2. 長期の更新トークンを短期のアクセストークンと交換します。この処理は、トークンが期限切れになり、新しいアクセストークンが必要になった場合に発生します。

OAuth 2.0 フローを選択する

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

設計ガイドライン

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

この図は、ユーザーが自身の Google アカウントをデベロッパーの認証システムにリンクする手順を示しています。最初のスクリーンショットは、プラットフォームからユーザーが開始するリンクを示しています。2 つ目の画像は Google へのユーザーのログインを示しています。3 つ目の画像は、Google アカウントとアプリをリンクすることに対するユーザーの同意と確認を示しています。最後のスクリーンショットは、Google アプリでユーザーアカウントが正常にリンクされた状態を示しています。 — **図 1.** アカウントリンクのユーザーが Google にログインする画面と同意画面。

要件

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

推奨事項

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

Google のプライバシーポリシーを表示する。同意画面に Google のプライバシーポリシーへのリンクを含めます。
共有するデータ。明確で簡潔な表現を使用して、Google に必要なデータとその理由をユーザーに伝えます。
行動を促す明確なフレーズ同意画面に「同意してリンク」など、わかりやすい行動を促すフレーズを表示します。これは、アカウントをリンクするために Google と共有する必要があるデータをユーザーが理解する必要があるためです。
キャンセルできること。ユーザーがリンクしないことを選択した場合に、ユーザーが戻るまたはキャンセルできる方法を提供します。
ログインプロセスを明確にする。ユーザーが Google アカウントにログインするための明確な方法（ユーザー名とパスワードのフィールド、Google でログインなど）があることを確認します。
リンクを解除できること。ユーザーがリンクを解除するためのメカニズム（プラットフォームのアカウント設定への URL など）を提供します。または、ユーザーがリンクされたアカウントを管理できる Google アカウントへのリンクを含めることもできます。
ユーザーアカウントを変更する機能。ユーザーがアカウントを切り替える方法を提案します。これは、ユーザーが複数のアカウントを持っている場合に特に便利です。
- ユーザーがアカウントを切り替えるために同意画面を閉じる必要がある場合は、回復可能なエラーを Google に送信して、ユーザーが OAuth リンクと暗黙的フローを使用して目的のアカウントにログインできるようにします。
ロゴを含めます。同意画面に会社のロゴを表示します。スタイルガイドラインに沿ってロゴを配置します。Google のロゴも表示する場合は、ロゴと商標をご覧ください。

创建项目

如需创建使用账号关联的项目，请执行以下操作：

点击 Create project。
输入名称或接受生成的建议。
确认或修改所有剩余字段。
点击创建。

如需查看项目 ID，请执行以下操作：

在着陆页的表格中找到您的项目。项目 ID 会显示在 ID 列中。

配置 OAuth 权限请求页面

Google 账号关联流程包含一个权限请求页面，该页面会告知用户哪个应用在请求访问其数据、请求访问哪些类型的数据，以及适用的条款。您需要先配置 OAuth 权限请求页面，然后才能生成 Google API 客户端 ID。

打开 Google API 控制台的 OAuth 同意屏幕页面。
如果出现提示，请选择您刚刚创建的项目。
在“OAuth 同意屏幕”页面上，填写表单，然后点击“保存”按钮。

应用名称：征求用户同意的应用的名称。名称应准确反映您的应用，并与用户在其他位置看到的应用名称保持一致。应用名称将显示在账号关联权限请求界面上。

应用徽标：权限请求页面上显示的一张图片，用以让用户认出您的应用。徽标会显示在账号关联权限请求页面和账号设置中

支持电子邮件地址：供用户就其同意问题与您联系。

Google API 的范围：借助范围，您的应用可以访问用户的非公开 Google 数据。对于 Google 账号关联使用情形，默认范围（电子邮件地址、个人资料、openid）就足够了，您无需添加任何敏感范围。一般来说，最佳做法是在需要访问权限时逐步请求权限范围，而不是提前请求。了解详情。

已获授权的网域：为了保护您和您的用户，Google 只允许使用 OAuth 进行身份验证的应用使用已获授权的网域。应用的链接必须托管在已获授权的网域上。了解详情。

应用首页链接：应用的首页。必须托管在已获授权的网域上。

应用隐私权政策链接：显示在 Google 账号关联意见征求界面上。必须托管在已获授权的网域上。

应用服务条款链接（可选）：必须托管在已获授权的网域上。

图 1. 虚构应用 Tunery 的 Google 账号关联意见征求界面
查看“验证状态”，如果您的应用需要验证，请点击“提交以供验证”按钮，提交应用以供验证。如需了解详情，请参阅 OAuth 验证要求。

OAuth サーバーを実装する

認可コードフローの OAuth 2.0 サーバー実装は、 2 つのエンドポイント（サービスから HTTPS で利用可能）最初のエンドポイント認可エンドポイントであり、サービスアカウントの検索、ユーザーの同意を得る。認可エンドポイントは、まだログインしていないユーザーにログイン UI を表示し、アクセス権を取得します。2 つ目のエンドポイントはトークン交換エンドポイントです。トークンと呼ばれる暗号化された文字列を取得し、ユーザーがサービスにアクセスします。

Google アプリケーションがサービスの API を呼び出す必要がある場合、Google はこれらの API を呼び出す権限をユーザーから取得できます。委任できます。

Google が開始した OAuth 2.0 認可コードフローセッションには、できます。

Google がユーザーのブラウザで認可エンドポイントを開きます。フローが音声のみのデバイスで開始された場合、Google はダウンロードします
ユーザーがログインし（まだログインしていない場合）、Google に次の権限を与える API を使用してデータにアクセスする必要があります（まだ権限を付与していない場合）。
サービスによって認証コードが作成され、Google に返されます。タスクそのため、認証コードを使用してユーザーのブラウザを Google にリダイレクトします。リクエストに添付されます
Google がトークン交換エンドポイントに認証コードを送信します。コードの真正性を検証し、アクセストークンと 更新トークン。アクセストークンは有効期間の短いトークンであり、サービスを受け入れて、API にアクセスするための認証情報です。更新トークンは有効期間が長いトークンを保存し、新しいアクセストークンを取得するために Google が使用期限が切れます。
ユーザーがアカウントのリンクのフローを完了すると、それ以降はリクエストにはアクセストークンが含まれています。

認可リクエストの処理

OAuth 2.0 認証コードを使用してアカウントリンクを行う必要がある場合リクエストが送信されると、Google はユーザーを認可エンドポイントに送信します。次のパラメータが含まれます。

認可エンドポイントのパラメータ
`client_id`	Google に割り当てたクライアント ID。
`redirect_uri`	このリクエストに対するレスポンスを送信する宛先 URL。
`state`	リダイレクト URL で変更されずに Google に返される会計上の値。
`scope`	省略可: スコープ文字列をスペースで区切って指定します。許可を求めているデータです。
`response_type`	レスポンスで返される値のタイプ。OAuth 2.0 では、認可コードフローでは、レスポンスタイプは常に `code` です。
`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&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

認可エンドポイントでログインリクエストを処理するには、次の操作を行います。手順:

client_id が、Google に割り当てたクライアント ID と一致することと、redirect_uri が、Google からサービスに提供されたリダイレクト URL と一致していることを確認します。これらのチェックは、権限の付与を防ぐために意図しないクライアントアプリへのアクセスを防止できます。複数の OAuth 2.0 フローの場合、response_type が code であることも確認します。
ユーザーがサービスにログインしているかどうか確認します。ユーザーがログインしていない場合は、サービスのログインまたは登録フローを完了します。
Google が API にアクセスするために使用する認証コードを生成します。認証コードには任意の文字列値を使用できますが、一意である必要があります。は、ユーザー、トークンの対象となるクライアント、コードの有効期限を表します。推測できないようにします。通常、約 10 分後に期限切れになる認可コードを発行します。

redirect_uri パラメータで指定された URL がフォーム:

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

ユーザーのブラウザを redirect_uri パラメータ。その際、認証コードをリダイレクトしたときに、変更されていない元の状態値が code パラメータと state パラメータを追加します。以下は、次のようになります。
```
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING
```

トークン交換リクエストの処理

サービスのトークン交換エンドポイントは、次の 2 種類のトークン交換を処理します。

認可コードとアクセストークンおよび更新トークンとの交換
更新トークンとアクセストークンの交換

トークン交換リクエストには、次のパラメータを使用します。

トークン交換エンドポイントのパラメータ
`client_id`	リクエスト元を Google として識別する文字列。この文字列は、Google の一意の識別子としてシステムに登録されている必要があります。
`client_secret`	Google に登録したサービスのシークレット文字列。
`grant_type`	交換されるトークンの種類。次のいずれか `authorization_code` または `refresh_token`。
`code`	`grant_type=authorization_code` の場合、このパラメータはログインまたはトークン交換から Google が受け取ったコード提供します
`redirect_uri`	`grant_type=authorization_code` の場合、このパラメータは最初の承認リクエストで使用される URL。
`refresh_token`	`grant_type=refresh_token` の場合、このパラメータは Google がトークン交換エンドポイントから受け取った更新トークン。

認可コードとアクセストークンおよび更新トークンとの交換

ユーザーがログインすると、認可エンドポイントから一時的な認証コードを Google に送信すると、Google がトークン交換にリクエストを送信し、認証コードをアクセストークンと交換して更新し、あります。

これらのリクエストでは、grant_type の値は authorization_code、 code の値は、以前に付与した認証コードの値です。 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=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

アクセストークンと更新トークンの認証コードを交換するには、トークン交換エンドポイントは、次の処理を実行して POST リクエストに応答します。手順:

client_id でリクエストの送信元が承認済みであることを確認する client_secret が期待値と一致することを確認します。
認証コードが有効で有効期限が切れていないこと、認証コードがリクエストで指定されたクライアント ID が、リクエストに関連付けられたクライアント ID と認証コード。
redirect_uri パラメータで指定された URL が同一であることを確認する初期承認リクエストで使用されている値に設定します。
上記の条件をすべて満たせない場合は HTTP を本文が {"error": "invalid_grant"} の 400 Bad Request エラー。
それ以外の場合は、認証コードのユーザー ID を使用して更新を生成するアクセストークンが含まれます。トークンには任意の文字列値を指定できますが、トークンを使用するユーザーとクライアントを一意に表し、推測できないようにしてください。アクセストークンについては、トークンの有効期限もトークン。これは通常、トークンを発行してから 1 時間です。更新トークンに有効期限はありません。

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 リクエストに応答します。

client_id がリクエスト元を Google として識別していることを確認します。 client_secret が期待値と一致することを確認します。
更新トークンが有効で、リクエストで指定されたクライアント ID が更新に関連付けられたクライアント ID と一致していることを確認します。
上記の条件をすべて満たせない場合は、HTTP 400 を返します。 {"error": "invalid_grant"} を本文とする不正なリクエストエラー。
それ以外の場合は、更新トークンのユーザー ID を使用してアクセストークンを生成します。これらのトークンは任意の文字列値にできますが、一意である必要があります。は、トークンの対象となるユーザーとクライアントを表します。これらは、あります。アクセストークンの場合は、トークンの有効期限、トークンを発行してから通常 1 時間後です。

HTTPS レスポンスの本文で次の JSON オブジェクトを返します。

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

で確認できます。

userinfo リクエストを処理する

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

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

トークンエンドポイントからアクセストークンが正常に取得されると、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 エラーレスポンスの例を次に示します。
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
```
リンク処理中に 401 Unauthorized またはその他の失敗したエラーレスポンスが返された場合、そのエラーは修復不能となり、取得したトークンは破棄されるため、ユーザーはリンク処理をやり直す必要があります。

アクセストークンが有効な場合は、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 ツールを使用します。

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

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

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

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

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