FedCM API を使用した Google ログイン

このガイドでは、Google ログイン プラットフォーム ライブラリによる FedCM API の採用について説明します。トピックには、ライブラリの下位互換性のある更新に関するタイムラインと次のステップ、影響評価を実施する方法とユーザーのログインが想定どおりに機能し続けることを確認する方法、必要に応じてウェブアプリを更新する手順が含まれます。移行期間を管理する方法とヘルプを受ける方法についても説明します。

ライブラリのステータス

新しいウェブアプリは、非推奨の Google ログイン プラットフォーム ライブラリの使用がブロックされますが、ライブラリを使用しているアプリは、当面は引き続き使用できます。ライブラリの最終的なサポート終了日（廃止）は確定していません。詳しくは、サポート終了と廃止をご覧ください。

下位互換性のある更新により、Google ログイン ライブラリに FedCM API が追加されました。ほとんどの変更はシームレスですが、この更新により、ユーザー プロンプト、iframe の permissions-policy、コンテンツ セキュリティ ポリシー（CSP）に違いが生じます。これらの変更はウェブアプリに影響し、アプリケーション コードとサイト構成の変更が必要になる場合があります。

移行期間中は、構成オプションでユーザーのログイン時に FedCM API を使用するかどうかを制御します。

移行期間後は、Google ログイン ライブラリを使用するすべてのウェブアプリで FedCM API が必須になります。

タイムライン

最終更新日: 2024 年 9 月

ユーザーのログイン動作に影響する日付と変更は次のとおりです。

• 2023 年 3 月 Google ログイン プラットフォーム ライブラリのサポート終了。
• 2024 年 7 月の移行期間が開始され、FedCM API の Google ログイン プラットフォーム ライブラリのサポートが追加されました。デフォルトでは、この期間に FedCM を使用してユーザーのログイン リクエストの割合を制御します。ウェブアプリでは、use_fedcm パラメータを使用してこの動作を明示的にオーバーライドできます。
• Google ログイン プラットフォーム ライブラリによる FedCM API の2025 年 3 月の必須導入。これ以降、use_fedcm パラメータは無視され、すべてのユーザー ログイン リクエストで FedCM が使用されます。

次のステップ

次の 3 つの方法から選択できます。

1. 影響評価を実施し、必要に応じてウェブアプリを更新します。このアプローチでは、ウェブアプリの変更が必要な機能が使用されているかどうかを評価します。手順については、このガイドの次のセクションをご覧ください。
2. Google Identity Services（GIS）ライブラリに移行します。サポートされている最新のログイン ライブラリに移行することを強くおすすめします。手順については、こちらをご覧ください。
3. 何もしない。Google ログイン ライブラリがユーザーのログイン用に FedCM API に移行すると、ウェブアプリは自動的に更新されます。最も簡単な方法ですが、ユーザーがウェブアプリにログインできなくなるリスクもあります。

影響評価を行う

以下の手順に沿って、下位互換性のあるアップデートでウェブアプリをシームレスに更新できるかどうか、または Google ログイン プラットフォーム ライブラリが FedCM API を完全に採用したときにユーザーがログインできないことを回避するために変更が必要かどうかを判断します。

セットアップ

ユーザーのログイン時に FedCM を使用するには、ブラウザ API と最新バージョンの Google ログイン プラットフォーム ライブラリが必要です。

続行する前に:

• パソコン版 Chrome を最新バージョンに更新します。Android 版 Chrome にはリリース M128 以降が必要です。以前のバージョンを使用してテストすることはできません。

• chrome://flags を開き、次の機能を次の値に設定します。

  • #fedcm-authz 有効
  • #tracking-protection-3pcd 有効
  • #third-party-cookie-deprecation-trial 無効
  • #tpcd-metadata-grants 無効
  • #tpcd-heuristics-grants 無効

  Chrome を再起動します。

• ウェブアプリで Google ログイン プラットフォーム ライブラリを初期化するときに、use_fedcm を true に設定します。通常、初期化は次のようになります。

  • gapi.client.init({use_fedcm: true})、または
  • gapi.auth2.init({use_fedcm: true})、または
  • gapi.auth2.authorize({use_fedcm: true})。

• Google ログイン プラットフォーム ライブラリのキャッシュ バージョンを無効にします。<script src> タグに api.js、client.js、または platform.js を含めることで、ライブラリの最新バージョンがブラウザに直接ダウンロードされるため、通常このステップは不要です（リクエストでは、ライブラリにこれらのバンドル名のいずれかを使用できます）。

• OAuth クライアント ID の OAuth 設定を確認します。

  1. Google API Consoleの [認証情報] ページを開きます

  2. ウェブサイトの URI が [承認済みの JavaScript 生成元] に含まれていることを確認します。URI には、スキームと完全修飾ホスト名のみが含まれます。例: https://www.example.com

  3. 必要に応じて、JavaScript コールバックではなく、ホストするエンドポイントへのリダイレクトを使用して認証情報を返すことができます。その場合は、リダイレクト URI が [承認済みのリダイレクト URI] に含まれていることを確認します。リダイレクト URI には、スキーム、完全修飾ホスト名、パスが含まれ、リダイレクト URI の検証ルールに準拠している必要があります。例: https://www.example.com/auth-receiver

テスト

設定の手順に沿って操作すると、次のように表示されます。

• 既存の Chrome シークレット ウィンドウをすべて閉じて、新しいシークレット ウィンドウを開きます。これにより、キャッシュに保存されているコンテンツや Cookie がすべて削除されます。
• ユーザーのログインページを読み込み、ログインを試みます。

• 既知の問題を特定して修正するには、このガイドの以下のセクションの手順を実施します。

  • Google ログイン ライブラリのリクエストを探す
  • iframe のアクセス許可ポリシーを確認する
  • コンテンツ セキュリティ ポリシーを確認する
  • ユーザー プロンプトの変更を確認する

• Google ログイン ライブラリに関連するエラーや警告がコンソールにないか確認します。

• エラーが発生せず、正常にログインできるようになるまで、このプロセスを繰り返します。ログインが成功したことを確認するには、BasicProfile.getEmail() がメールアドレスを返すことと、GoogleUser.isSignedIn() が True であることを確認します。

Google ログイン ライブラリのリクエストを探す

Google ログイン プラットフォーム ライブラリのリクエストを調べて、permissions-policy とコンテンツ セキュリティ ポリシーの変更が必要かどうかを確認します。これを行うには、ライブラリの名前とオリジンを使用してリクエストを探します。

• Chrome で DevTools の [ネットワーク] パネルを開き、ページを再読み込みします。
• [Domain] 列と [Name] 列の値を使用して、ライブラリ リクエストを見つけます。
  • ドメインは apis.google.com で、
  • 名前は、api.js、client.js、platform.js のいずれかです。Name の具体的な値は、ドキュメントで要求するライブラリ バンドルによって異なります。

たとえば、[ドメイン] 列の apis.google.com と [名前] 列の platform.js でフィルタします。

iframe の permissions-policy を確認する

サイトでクロスオリジン iframe 内で Google ログイン プラットフォーム ライブラリを使用しているとします。ある場合は、更新が必要です。

Google ログイン ライブラリ リクエストを見つけるの手順に沿って、DevTools の [ネットワーク] パネルで Google ログイン ライブラリ リクエストを選択し、[ヘッダー] タブの [リクエスト ヘッダー] セクションで Sec-Fetch-Site ヘッダーを見つけます。ヘッダーの値が次のいずれかの場合:

• same-site または same-origin の場合、クロスオリジン ポリシーは適用されず、変更は必要ありません。
• iframe を使用している場合は、cross-origin の変更が必要になる場合があります。

iframe が存在するかどうかを確認するには:

• Chrome DevTools で [要素] パネルを選択し、
• Ctrl+F を使用して、ドキュメント内の iframe を見つけます。

iframe が見つかった場合は、ドキュメントを検査して、iframe 内に Google ログイン ライブラリを読み込む gapi.auth2 関数または script src ディレクティブの呼び出しを確認します。上記が該当する場合は、次の手順を実施してください。

• 親 iframe に allow="identity-credentials-get" 権限ポリシーを追加します。

ドキュメント内のすべての iframe に、この手順を繰り返します。iframe はネストできるため、周囲のすべての親 iframe に allow ディレクティブを追加してください。

コンテンツ セキュリティ ポリシーを確認する

サイトでコンテンツ セキュリティ ポリシーを使用している場合は、Google ログイン ライブラリの使用を許可するように CSP を更新する必要があります。

Google ログイン ライブラリ リクエストを見つけるの手順に沿って、DevTools の [Network] パネルで Google ログイン ライブラリ リクエストを選択し、[Headers] タブの [Response Headers] セクションで Content-Security-Policy ヘッダーを見つけます。

ヘッダーが見つからない場合は、変更する必要はありません。それ以外の場合は、これらの CSP ディレクティブが CSP ヘッダーで定義されているかどうかを確認し、次のように更新します。

• https://apis.google.com/js/、https://accounts.google.com/gsi/、https://acounts.google.com/o/fedcm/ を任意の connect-src、default-src、または frame-src ディレクティブに追加する。

• script-src ディレクティブに https://apis.google.com/js/bundle-name.js を追加します。bundle-name.js は、ドキュメントがリクエストするライブラリ バンドルに応じて、api.js、client.js、または platform.js に置き換えます。

ユーザー プロンプトの変更を確認する

ユーザー プロンプトの動作にはいくつかの違いがあります。FedCM では、ブラウザに表示されるモーダル ダイアログが追加され、ユーザーの有効化要件が更新されます。

モーダル ダイアログ

サイトのレイアウトを調べて、基盤となるコンテンツをブラウザのモーダル ダイアログで安全に重ねて、一時的に隠すことができることを確認します。そうでない場合は、ウェブサイトの一部要素のレイアウトや位置を調整する必要があります。

ユーザーのアクティベーション

FedCM には、ユーザーの有効化要件の更新が含まれています。ボタンの押下やリンクのクリックは、サードパーティ オリジンがネットワーク リクエストを実行したりデータを保存したりできるようにするユーザー操作の例です。FedCM では、以下の場合にブラウザからユーザーの同意を求めるメッセージが表示されます。

• ユーザーが新しいブラウザ インスタンスを使用してウェブアプリに初めてログインした場合、または
• GoogleAuth.signIn が呼び出されます。

現在、ユーザーがウェブサイトにログインしたことがあれば、gapi.auth2.init を使用して Google ログイン ライブラリを初期化するときに、ユーザーの操作なしでユーザーのログイン情報を取得できます。ユーザーが FedCM のログインフローを少なくとも 1 回行わない限り、この方法は使用できなくなります。

FedCM にオプトインして GoogleAuth.signIn を呼び出すと、同じユーザーが次回ウェブサイトにアクセスしたときに、gapi.auth2.init はユーザーの操作なしで初期化中にユーザーのログイン情報を取得できます。

一般的なユースケース

Google ログイン ライブラリのデベロッパー向けドキュメントには、一般的なユースケースのガイドとコードサンプルが含まれています。このセクションでは、FedCM がその動作にどのように影響するかについて説明します。

• ウェブ アプリケーションへの Google ログインの統合

  このデモでは、<div> 要素とクラスがボタンをレンダリングします。すでにログインしているユーザーの場合、ページ onload イベントによってユーザー認証情報が返されます。ログインして新しいセッションを確立するには、ユーザーの操作が必要です。

  ライブラリの初期化は、gapi.load と gapi.auth2.init を呼び出す g-signin2 クラスによって行われます。

  ユーザー操作（<div> 要素の onclick イベント）は、ログイン時に auth2.signIn を呼び出し、ログアウト時に auth2.signOut を呼び出します。

• カスタムの Google ログインボタンを作成する

  デモ 1 では、カスタム属性を使用してログインボタンの外観をコントロールしています。すでにログインしているユーザーに対して、ページの onload イベントによってユーザー認証情報が返されます。ログインして新しいセッションを確立するには、ユーザーの操作が必要です。

  ライブラリの初期化は、platform.js ライブラリの onload イベントを介して行われ、ボタンは gapi.signin2.render によって表示されます。

  ユーザーがログインボタンを押すと、auth2.signIn が呼び出されます。

  デモ 2 では、<div> 要素、CSS スタイル、カスタム グラフィックを使用して、ログイン ボタンの外観を制御しています。ログインして新しいセッションを確立するには、ユーザーの操作が必要です。

  ライブラリの初期化は、ドキュメントの読み込み時に gapi.load、gapi.auth2.init、gapi.auth2.attachClickHandler を呼び出す start 関数を使用して行われます。

  ユーザー操作（<div> 要素の onclick イベント）は、ログイン時に auth2.attachClickHandler を使用して auth2.signIn を呼び出し、ログアウト時に auth2.signOut を呼び出します。

• ユーザーのセッション状態のモニタリング

  このデモでは、ボタンの押下によってユーザーのログインとログアウトが行われます。ログインして新しいセッションを確立するには、ユーザーの操作が必要です。

  ライブラリの初期化は、script src を使用して platform.js を読み込んだ後に、gapi.load、gapi.auth2.init、gapi.auth2.attachClickHandler() を直接呼び出すことで行われます。

  ユーザー操作（<div> 要素の onclick イベント）は、ログイン時に auth2.attachClickHandler を使用して、ログアウト時に auth2.signOut を使用して auth2.signIn を呼び出します。

• 追加の権限をリクエストする

  このデモでは、ボタンを押して追加の OAuth 2.0 スコープをリクエストして新しいアクセス トークンを取得します。すでにログインしているユーザーの場合、ページの onload イベントによってユーザー認証情報が返されます。ログインして新しいセッションを確立するには、ユーザーの操作が必要です。

  ライブラリの初期化は、gapi.signin2.render の呼び出しを介して platform.js ライブラリの onload イベントによって行われます。

  ユーザー操作（<button> 要素）をクリックすると、ログアウト時に googleUser.grant または auth2.signOut を使用する追加の OAuth 2.0 スコープのリクエストがトリガーされます。

• リスナーを使用した Google ログインの統合

  このデモでは、すでにログインしているユーザーの場合、ページ onload イベントがユーザー認証情報を返します。ログインして新しいセッションを確立するには、ユーザーの操作が必要です。

  ライブラリの初期化は、gapi.load、gapi.auth2.init、gapi.auth2.attachClickHandler を呼び出す開始関数を使用して、ドキュメントの読み込み時に行われます。次に、auth2.isSignedIn.listen と auth2.currentUser.listen を使用して、セッション状態の変更の通知を設定します。最後に、auth2.SignIn が呼び出され、ログイン中のユーザーの認証情報が返されます。

  ユーザー操作（<div> 要素の onclick イベント）は、ログイン時に auth2.attachClickHandler を使用して auth2.signIn を呼び出し、ログアウト時に auth2.signOut を呼び出します。

• サーバーサイド アプリ向け Google ログイン

  このデモでは、ユーザー操作を使用して OAuth 2.0 認可コードをリクエストし、JS コールバックが AJAX 呼び出しを行い、バックエンド サーバーにレスポンスを送信して検証します。

  ライブラリの初期化は、platform.js ライブラリの onload イベントを使用して行われます。このライブラリは start 関数を使用して、gapi.load と gapi.auth2.init を呼び出します。

  ユーザー操作（<button> 要素）をクリックすると、auth2.grantOfflineAccess を呼び出して認証コードのリクエストがトリガーされます。

• クロス プラットフォーム SSO

  FedCM では、ブラウザ インスタンスごとに同意が必要です。Android ユーザーがすでにログインしている場合でも、1 回限りの同意が必要です。

移行期間を管理する

移行期間中、ユーザーのログインの一部で FedCM が使用される場合があります。正確な割合は変動し、時間の経過とともに変更される可能性があります。デフォルトでは、FedCM を使用するログイン リクエストの数は Google が制御しますが、移行期間中は FedCM の使用を有効または無効にできます。移行期間の終了後、FedCM は必須となり、すべてのログイン リクエストで使用されます。

オプトインを選択すると、ユーザーは FedCM ログイン フローに送信されます。オプトアウトを選択すると、ユーザーは既存のログイン フローに送信されます。この動作は、use_fedcm パラメータを使用して制御します。

オプトイン

サイトへのログイン試行のすべてまたは一部で FedCM API を使用するかどうかを制御することをおすすめします。そのためには、プラットフォーム ライブラリを初期化するときに use_fedcm を true に設定します。この場合、ユーザーのログイン リクエストは FedCM API を使用します。

オプトアウト

移行期間中、サイトへのユーザーのログイン試行の一部は、デフォルトで FedCM API を使用します。アプリの変更にさらに時間が必要な場合は、FedCM API の使用を一時的にオプトアウトできます。そのためには、プラットフォーム ライブラリを初期化するときに use_fedcm を false に設定します。この場合、ユーザーのログイン リクエストは FedCM API を使用しません。

必須の導入後は、Google ログイン プラットフォーム ライブラリで use_fedcm 設定は無視されます。

ヘルプ

StackOverflow で google-signin タグを使用して検索または質問します。