Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Google Cloud と OAuth を設定する

Google Health API へのアクセスは Google Cloud を通じて提供されます。API を有効にして Google アカウントを承認するには、Google Cloud プロジェクトが必要です。

Fitbit API をすでに利用しているデベロッパーも、Google Health API を初めて利用するデベロッパーも、API を呼び出すにはこの手順を完了する必要があります。

プロジェクトと OAuth クライアントを作成する

[API を有効にして OAuth 2.0 クライアント ID を取得] ボタンを使用して、Google Health API を有効にして OAuth 2.0 クライアント ID を取得します。

Google Health API で使用する既存の Google Cloud プロジェクトがある場合は、まずそのプロジェクトの管理者アカウントにログインしていることを確認します。次に、ボタンをクリックして、使用可能なプロジェクトのリストから既存のプロジェクトを選択します。それ以外の場合は、新しいプロジェクトを作成します。
[呼び出し元] で [ウェブサーバー] を選択します。
[承認済みのリダイレクト URI] に「 https://www.google.com」と入力します。OAuth 2.0 を使用して認可コードを取得するには、リダイレクト URI が必要です。
設定が完了したら、OAuth 2.0 クライアント ID とクライアントシークレットの値をコピーし、認証情報 JSON をローカルマシンにダウンロードします 。

Google Cloud プロジェクトを手動で設定する場合、または設定を確認して認証情報を再度取得する場合は、次の操作を行います。

[Google Health API] を [API の有効化] ページで有効にします。
[認証情報] ページで OAuth 2.0 クライアント ID を取得します。

Google コンソールを使用して OAuth 2.0 を設定する方法について詳しくは、 OAuth 2.0 を使用した Google API へのアクセスをご覧ください。

テストユーザーを追加する

デフォルトでは、新しく作成された OAuth クライアントは未確認の状態であり、テストと本番環境の両方で 100 人のユーザーに制限されています。この期間中に承認を有効にするには、プロジェクト構成のテストユーザーリストに各ユーザーのメールアドレスを手動で追加する必要があります。

[オーディエンス] ページでテストユーザーのリストを更新します。

このページで、[公開ステータス] が [**テスト中**] に、 [ユーザーの種類] が [**外部**] に設定されていることを確認します。
[テストユーザー] セクションで、[**+ ユーザーを追加**] をクリックします。アプリに健康に関するデータへのアクセス権を付与できるようにするテストユーザーのメールアドレスを入力します。
[保存] をクリックします。

Google Health API で 100 人を超えるユーザーをサポートするには、サードパーティのセキュリティレビューを完了する必要があります。詳細については、OAuth アプリの確認に関するヘルプセンターをご覧ください。

スコープを追加する

[データアクセス] ページで、クライアントが呼び出すことができるスコープを指定する必要があります。

このページで、[スコープを追加または削除] をクリックします。
[API] 列で「Google Health API」を検索します。アプリケーションに必要なスコープを選択します。
必要なスコープをすべて選択したら、[更新] をクリックして [データアクセス] ページに戻ります。
[保存] をクリックします。

スコープを選択する前に、スコープの実装を確認してください。

クライアント ID の設定が完了し、Google Health API を呼び出せるようになりました。

スコープの更新

認証リクエストで prompt パラメータを consent に設定すると、ユーザーにアプリの再承認を求めることができます。prompt=consent が含まれている場合、すべてのスコープが Google API プロジェクトにすでに付与されている場合でも、アプリがアクセスのスコープの承認をリクエストするたびに同意画面が表示されます。

prompt=consent パラメータを使用してスコープを追加または変更する手順は次のとおりです。

アプリケーションに必要なスコープの完全なリストを特定します。これには、既存のスコープと、追加する必要がある新しいスコープの両方が含まれます。
認可 URL の scope パラメータを変更して、スペース区切りのスコープ値の更新されたリストを含めます。
認証 URI パラメータに prompt=consent を追加します。これにより、認可サーバーはクライアントに情報を返す前に、ユーザーに同意を求めるようになります。

次の例は、prompt=consent が追加された複数のスコープをリクエストする Google の OAuth 2.0 認可エンドポイントへの HTTPS GET リクエストを示しています。
```
https://accounts.google.com/o/oauth2/v2/auth?client_id=client-id&redirect_uri=redirect-uri&response_type=code&access_type=offline&scope=https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly%20https://www.googleapis.com/auth/googlehealth.sleep.readonly&prompt=consent
```
ユーザーが更新されたリンクをクリックすると、リクエストされたすべてのスコープが一覧表示された同意ページが表示されます。ユーザーが [続行] または [許可] をクリックすると、すべてのスコープをカバーするトークンと交換できる新しい認証コードが届きます。

prompt=consent は、新しい更新トークンを取得する必要がある場合や、リクエストされたスコープが変更された場合など、必要な場合にのみ含めます。

OAuth2 クライアントライブラリ

一般的なフレームワークとの統合に使用される使用可能な OAuth2 クライアントライブラリのリストについては、 OAuth 2.0 を使用した Google API へのアクセスをご覧ください。

更新トークン

ユーザーの再認証を頻繁に行うことなく Google API への長期的なアクセスを維持するには、アプリケーションで更新トークンを使用する必要があります。必要な特定の HTTP リクエストとパラメータなど、実装の詳細については、Google Identity Platform のドキュメントをご覧ください。

更新トークンとアクセストークンを交換するには、Google OAuth 2.0 トークンエンドポイントに HTTPS POST 呼び出しを行います。次のスニペットは、リクエストとレスポンスの例を示しています。

リクエスト

curl -L -X POST 'https://oauth2.googleapis.com/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'client_id=client-id&client_secret=client-secret&refresh_token=refresh-token&grant_type=refresh_token'

レスポンス

{
  "access_token": "access-token",
  "expires_in": 3599,
  "scope": "scope-list",
  "token_type": "Bearer",
  "refresh_token": "refresh-token",
  "refresh_token_expires_in": 112154
}

トークンを更新するタイミング

アクセストークンの有効期限が切れた場合や有効期限が近づいている場合は、ユーザーのアクティブセッションの自然な進行の一部として、オンデマンドで更新トークンを更新します。トークンをバッチで更新することは避けてください（たとえば、スケジュールされた cron ジョブまたはサービスを使用して、すべてのユーザーのトークンを固定時間に更新するなど）。

バッチでトークンを更新することは、次の理由でおすすめしません。

バッチ更新では、トークンの更新をアクティブなユーザーの同期パターンに合わせることができません。Get Devices 呼び出しを使用してユーザーの最終同期時刻を確認できますが、これにはユーザーが承認する必要のない追加の OAuth スコープが必要です。
バッチ処理では、更新する必要のないトークンが更新されるため、システムと Google のサーバーの両方で冗長な処理オーバーヘッドが発生します。
バッチ更新中にネットワークの問題やサーバーの停止が発生すると、影響を受けるすべてのユーザートークンに同時に影響します。ユーザーの同期の自然な進行中にトークンを個別に更新すると、一時的な障害の影響を 1 人のユーザーに限定できます。
バッチジョブでは問題の診断が難しくなります。バッチリクエストの頻度が低く、ログエントリが一度に大量に生成されるため、インシデントの開始を特定するのが難しくなります。
バッチ実行中にトークンリクエストが急増すると、レート制限に達したり、断続的な認証エラーが発生したりする可能性が高くなります。

テスト中のトークンの動作

Google Cloud プロジェクトの公開ステータスに応じて更新トークンがどのように動作するかを把握しておきましょう。

テストモード: OAuth 同意画面が [テスト中] の公開ステータスで構成されている場合、発行される更新トークンは時間ベースで、7 日後に有効期限が切れます。この期間中、有効期限が切れるまで有効で、新しいアクセストークンの取得に使用できる更新トークンが 1 つ届きます。
公開モード: アプリが [本番環境] ステータスに移行すると、更新トークンは通常、取り消されるか、長期間（通常は 6 か月）使用されない限り有効期限が切れません。

シームレスなユーザーエクスペリエンスを実現するには、7 日間のトークンの有効期限が切れないように、アプリを本番環境に移行する前に公開してください。

クロスアカウント保護機能（RISC API）

イベントトークンやアカウントのリンク（切断されたアカウントや取り消されたトークンなど）の変更について通知を受け取り、保存されているトークンをクリーンアップして UI 接続ステータスを更新する場合は、リスクとインシデントの共有と調整（RISC）を有効にします。RISC API の有効化は任意です。

Google Cloud プロジェクトで RISC API を有効にするには:

Google Cloud コンソールで RISC API ページを開きます。Google Health API で使用するプロジェクトが選択されていることを確認します。
RISC の利用規約を読み、要件を理解していることを確認します。
利用規約に同意する場合は、[有効にする] をクリックします。

API を有効にしたら、Google から送信されたイベントトークンを受信して検証するための HTTPS エンドポイントを作成して登録する必要があります。

クロスアカウント保護機能と RISC の詳細については、クロスアカウント保護機能でユーザーアカウントを保護するをご覧ください。

Google Cloud と OAuth を設定する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。