統合に関する考慮事項

このステップバイステップ ガイドでは、統合に関するすべての主要な問題について意思決定を行うことができます。

概要の [Google でログイン]

ユーザーがウェブサイトにログインまたは登録する一般的な手順は次のとおりです。

1. ユーザーが Google ウェブサイトにログインします。

   「Google でログイン」を使用するには、ブラウザで有効な Google セッションが必要です。ワンタップと自動ログインは、ユーザーがウェブページの読み込み前に Google にログインしている場合にのみトリガーされます。[Google でログイン] ボタンのフローでは、ボタンが押されたときにユーザーに Google へのログインを求めるメッセージが表示されるため、このステップは省略可能です。

   キーポイント: セキュリティ上の理由から、iframe に新しい Google セッションを追加することはできません。

2. ユーザーが、ワンタップ、自動ログイン、または「Google でログイン」ボタンが埋め込まれたウェブページを閲覧している。

   重要なポイント: コード生成ツールを使用して、ワンタップ、自動ログイン、Google でログイン ボタンをウェブページに埋め込むコードを生成できます。

3. ユーザーは、ワンタップ、[Google でログイン] ボタン、その後の UX フローを操作して、次の操作を行います。

   • 続行するには、有効な Google セッションを選択してください。
   • プロフィール情報をウェブサイトと共有することについて、エンドユーザーから同意を得ます（まだ同意していない場合）。
   主なポイント: 自動ログインは、1 つのアクティブな Google セッションでのみ権限が付与され、ウェブサイトでこの機能が有効になっている場合に行われます。
   注: 自動ログインは、ワンタップ UX でのみ行われます。「Google でログイン」ボタンの UX では行えません。

   ブラウザでアクティブな Google セッションが 1 つしかない場合、

   • ワンタップでは、唯一のセッションが自動的に選択されるため、アカウント選択ページはスキップされます。
   • [Google でログイン] ボタンはアカウント選択ページに残るため、必要に応じてユーザーが新しい Google セッションを追加できます。

   選択した Google アカウントがウェブサイトでこれまで使用されたことがない場合や、権限が取り消されている場合は、同意ページが表示されます。

   

   承認されると、Google は決定を記録し、次回以降は同意ページをスキップします。

4. ユーザーの名前、メールアドレス、プロフィール写真を含む JSON ウェブトークン（ID トークン）の認証情報は、JavaScript コールバック ハンドラまたはバックエンド サービスへの投稿送信のいずれかを使用して共有されます。

   クライアントサイドの JavaScript コールバック ハンドラに ID トークンを返す目的は、JavaScript コードでデコードするためではなく、独自の方法でサーバーに送信するためです。たとえば、XmlHttpRequest を使用して、投稿送信によるページの再読み込みを回避できます。

   主なポイント: ウェブページを再読み込みせずに認証するには、JavaScript コールバック ハンドラを介して JWT 認証情報を受け取り、XmlHttpRequest を介してサーバーに送信するのが一般的です。

5. サーバー側では、Google が発行した JWT 認証情報が検証され、新しいアカウントの作成やウェブサイトでの認証済みセッションの確立に使用されます。

   ユーザーのログイン ステータスは、ご自身のウェブサイトで管理します。

   ユーザーの Google アカウントのログイン ステータスとアプリは、ユーザーが正常に認証され、Google アカウントにログインしていることが判明したログイン時を除き、相互に独立しています。ユーザーは、ウェブサイトでログインしたままのセッションを維持しながら、ログインしたままにするか、ログアウトするか、別の Google アカウントに切り替えることができます。

要約すると、パスワードベースのログインと同様に、「Google でログイン」はウェブでユーザーを認証する別の方法です。「Google でログイン」には、認証後のウェブサイトのセッション管理機能はありません。

Google API とサービスにアクセスする

前述のように、認証 API を統合しましたが、サイトが認証済みユーザーに代わって Google API とサービスにアクセスする必要がある場合は、承認 API を統合することも必要になる場合があります。認証では、ユーザーを認証するための ID トークンがサイトに提供されますが、承認では、Google API とサービスを使用するための（別の）アクセス トークンと権限がサイトに提供されます。詳細については、ウェブでの承認をご覧ください。

認証と認可の UX の分離

ウェブサイトで認証 API と承認 API の両方を呼び出す必要がある場合は、それぞれ異なるタイミングで呼び出す必要があります。認証と承認のタイミングを分離するをご覧ください。

ウェブサイトでこれまで認証トークンと認可トークンを一緒にリクエストしていた場合は、Google Identity Services JavaScript ライブラリを使用する際に、認証と認可のタイミングを分離するように UX を調整する必要があります。

• 認証時に、ウェブサイトにワンタップ、自動ログイン、または「Google でログイン」ボタンを統合して、ユーザーがウェブサイトにログインまたは登録できるようにします。
• 承認時に、ウェブサイトは認可 API を呼び出して、Google API またはサービスにアクセスするための権限とトークンを取得できます。

UX の移行をスムーズにし、複雑さを軽減するために、プロセスを 2 つの個別のステップに分割するのが一般的です。

1. 認証と認可のタイミングを分離するように UX をリファクタリングします。

2. Google Identity Services JavaScript ライブラリに移行します。

   キーポイント: 以降では、認証モーメント API とその機能について説明します。認可モーメント API と機能については、認可 API のドキュメントをご覧ください。

HTML API と JavaScript API

HTML API または JavaScript API を使用して、ワンタップ、自動ログイン、または Google でログインボタンをウェブページに統合できます。

HTML API には、組み込み機能がさらに多く用意されています。次に例を示します。

• ページ読み込み時にワンタップまたは [Google でログイン] ボタンをレンダリングする。
• ワンタップ、自動ログイン、またはボタンのポップアップ/リダイレクト UX が完了したら、返された認証情報をサーバーサイド エンドポイント（data-login_uri 属性で指定）に送信します。
• double-submit-cookie を使用して CSRF 攻撃を防ぎます。
• コード生成ツールを使用して HTML コードを生成し、HTML ページにコピーします。

HTML API を使用すると、JavaScript を記述して動作をカスタマイズすることもできます。

• 独自のコールバック ハンドラを記述し、関数名を data-callback 属性に設定できます。たとえば、XmlHttpRequest を使用して返された認証情報をサーバーに送信し、デフォルトの POST 送信によるページの再読み込みを回避できます。

  キーポイント: ウェブページを再読み込みせずに認証するには、JavaScript コールバック ハンドラで JWT 認証情報を受信し、XmlHttpRequest を使用してサーバーに送信するのが一般的です。

JavaScript API を使用すると、一部のシナリオで柔軟性を高めることができます。

• ワンタップと [Google でログイン] ボタンのレンダリングを後回しにする。たとえば、ユーザーがメニューから [ログイン] を選択した後です。
• API を複数回呼び出す。たとえば、ログイン ダイアログがレンダリングされるたびに、[Google でログイン] ボタンをレンダリングする必要があります。
• HTML ページが動的に生成されるため、API 呼び出しコードを埋め込むのが難しい。
• Google Identity Services JavaScript ライブラリを後で読み込みます。

HTML API コードは、ページの onload イベントまたは Google Identity Services JavaScript ライブラリの onload イベントのいずれか（後者）で 1 回だけ呼び出すことができます。HTML API の動作が期待どおりでない場合は、JavaScript API を使用する必要があります。

注: 可能であれば HTML API を使用することをおすすめします。

ページの初期化やワンタップとボタンのレンダリングに、同じウェブページで HTML API と JavaScript API を併用しないでください。HTML と JavaScript の両方のコードで、重複する部分がないか確認します。次の点にご留意ください。

• HTML コードに <div id='g_id_onload' ... ><id> または <div class='g_id_signin' ...></div> の要素が 1 つ以上存在する場合は、HTML API を使用しています。
• JavaScript コードで initialize()、prompt()、render() のいずれかのメソッドが 1 つ以上呼び出されている場合、JavaScript API を使用しています。これらのメソッドがインライン化されているか、別の JavaScript ファイルから読み込まれているかは関係ありません。

警告: ページの初期化やワンタップとボタンのレンダリングに、同じウェブページで HTML API と JavaScript API の両方を使用すると、ワンタップとボタンが 2 回レンダリングされるなど、厄介なバグが発生する可能性があります。

次の JavaScript API は、初期化やワンタップ、ボタンのレンダリングとは別に使用できます。これらの API には対応する HTML API はありません。

• revoke
• cancel
• disableAutoSelect
• storeCredential

[Google でログイン] ボタンに関する考慮事項

このセクションでは、[Google でログイン] ボタンをウェブサイトに統合する際の考慮事項について説明します。

ポップアップとリダイレクトの違い

OAuth 2.0 仕様では HTTP リダイレクトが考慮されていますが、ポップアップ ダイアログのレンダリングに関するガイダンスはありません。ポップアップの UX は、特にパソコンのウェブでは、エンドユーザーにとって優れた UX を提供できる場合があります。これは、ユーザーがサードパーティのページからリダイレクトされず、ダイアログ タイプのポップアップ ウィンドウでコンテキストに沿った権限付与エクスペリエンスが提供されるためです。

ポップアップ UX では、ID プロバイダは、クライアントサイドのクロスオリジン通信チャネルを構築して、ID プロバイダの同意ページが表示されるポップアップ ウィンドウから、サードパーティ ページが表示されるメイン ウィンドウに OAuth レスポンスを渡す必要があります。通常、ウィンドウ間で OAuth レスポンスを送受信するには、両側で JavaScript コードが必要です。

「Google でログイン」ボタンでは、ポップアップとリダイレクトの両方の UX がサポートされています。デフォルトでは、ポップアップ UX が使用されます。UX は、data-ux_mode 属性を設定することで変更できます。

キーポイント: [Google でログイン] ボタンはポップアップ UX をサポートしています。

[Google でログイン] ボタンのリダイレクト フローには、OAuth リダイレクト フローとは異なる点があります。

• [Google でログイン] ボタンのリダイレクト フローでは、常に POST メソッドを使用して認証情報をウェブサーバーに送信しますが、OAuth リダイレクトでは通常 GET メソッドが使用されます。
• [Google でログイン] ボタンのリダイレクト フローによって送信されるパラメータは、OAuth リダイレクト フローのものと異なります。

HTML API を使用するデベロッパーの場合、どの UX を使用しても、認証情報は常に POST メソッドと同じパラメータを使用して data-login_uri に送信されます。これにより、他のコードを変更せずに UX モードを切り替えることができます。リダイレクト UX の場合は、Google APIs コンソールでクライアントの [承認済みのリダイレクト URI] に data-login_uri を追加する必要があります。

キーポイント: 「Google でログイン」ボタンのリダイレクト フロー、OAuth リダイレクト フローの違いに注意してください。

ボタンのカスタマイズ

独自のボタンは使用できません。ボタンフローをプログラムで開始する API はありません。

[Google でログイン] ボタンフローを有効にするには、ウェブページに 1 つ以上の [Google でログイン] ボタンを表示するだけです。ボタンフローは、ユーザーがこれらのボタンをクリックしたときに開始され、透過的に処理されます。

ボタン レンダリング API を使用すると、[Google でログイン] ボタンの外観をカスタマイズできます。コード生成ツールを使用して、ボタンをインタラクティブに設計することをおすすめします。JavaScript API を使用している場合でも、まず HTML コードを生成し、そのコードを JavaScript API の対応するフィールドにコピーできます。

ウェブサイトが、ボタンのレンダリングにパーソナライズド情報を使用するかどうかを制御できる API はありません。すべての条件が満たされると、パーソナライズされたボタンが表示されます。詳しくは、パーソナライズ ボタンについてをご覧ください。

同じウェブページに複数のボタンを配置できます。コード生成ツールで作成できるボタンは 1 回につき 1 つだけです。これを複数回実行し、生成された <div class='g_id_signin' ...></div> コードをウェブページにコピーできます。

警告: 同じウェブページに含めることができる <div id='g_id_onload' ... ><id> 要素は 1 つだけです。複数の g_id_onload 要素をウェブページにコピーしないでください。

ボタンのレンダリングに関するベスト プラクティス

プライバシー上の理由から、パーソナライズされたボタンは accounts.google.com ドメインの iframe に表示されます。ネットワークが遅い場合、iframe の読み込みに時間がかかることがあります。このレイテンシの問題を軽減するため、ボタンは次の 2 つのステップでレンダリングされます。

1. インライン ボタン バージョンは、ウェブサイトの DOM ツリーにレンダリングされます。単なるテキスト ボタンであり、パーソナライズされた情報は使用できません。これは、ユーザーがボタンをできるだけ早く表示できるようにするためのものです。
2. ボタンの iframe を読み込むために iframe リクエストが Google に送信されます。この iframe には、パーソナライズされた情報が含まれている場合があります。ボタンの iframe が読み込まれると、インライン バージョンのボタンは削除されます。

[Google でログイン] ボタンフローの表示レイテンシを最小限に抑えるためのベスト プラクティスをいくつか示します。

• Google Identity Services JavaScript ライブラリはできるだけ早く読み込みます。特にモバイルウェブでは、他の大きなライブラリの前に JavaScript ライブラリを読み込むことを検討してください。

• ユーザーがメニューから [ログイン] を選択した後にのみ、[Google でログイン] ボタンが表示されます。最初は [Google でログイン] ボタンを非表示要素でレンダリングし、ユーザーがメニューから [ログイン] を選択した後に表示するようにします。

  キーポイント: Google Identity Services JavaScript ライブラリをできるだけ早く読み込み、[Google でログイン] ボタンの表示の遅延を最小限に抑えます。

One Tap に関する考慮事項

自動ログイン

自動ログイン機能を使用すると、ユーザーはウェブサイトへのアクセスを許可している場合に、ワンタップ プロンプトをクリックせずにウェブサイトにログインできます。

キャンセル可能な自動ログインには、次のような利点があります。

• ユーザーのアクションを 1 つ減らすことで、ログイン率を改善できる可能性があります。
• 以前の非推奨の Google Sign-In JavaScript ライブラリで提供されていたサイレント ログインとは異なり、自動ログインが発生すると、ユーザーには常に UI が表示されます。これにより、ウェブサイトにログインする理由と方法のコンテキストがユーザーに提示されます。お客様は必要に応じて解約することもできます。
• ユーザーが以前に使用したアカウントが自動的に選択されるため、ユーザーがウェブサイトで重複するアカウントを作成できない場合があります。

自動ログインを有効にするかどうかは、ウェブサイトの UX とビジネス要件に基づいて判断する必要があります。特に、ウェブサイトからのログアウトのほとんどが、ユーザーの明示的な選択ではなくセッションのタイムアウトによって発生する場合は、自動ログインがユーザーがセッション ステータスを復元するための良い方法になる可能性があります。

ワンタップ UI を表示するタイミング

HTML API では、ワンタップはページの読み込み時に常に表示されます。JavaScript API を使用すると、ワンタップ UI を表示するタイミングを制御できます。次の理由により、API の呼び出し後にワンタップ UI が表示されない場合があります。

• ブラウザでアクティブな Google セッションがない。
• アクティブな Google セッションはすべてオプトアウトされています。
• クールダウン中です。

ボタンのクリック イベントでワンタップ UI のみを表示しようとしないでください。上記の理由により、ワンタップ UI が表示されない場合があります。また、ユーザーの操作後に何も表示されないため、ユーザー エクスペリエンスが損なわれる可能性があります。ボタンのクリック イベント:

推奨

• パスワード ログインと [Google でログイン] ボタンを含むログイン ダイアログを表示し、同時に One Tap API を呼び出します。これにより、ユーザーは常にウェブサイトへのログイン方法を提示されるようになります。

非推奨

• ワンタップのみを提供している場合、ワンタップが表示されないと、ユーザーはログインできない可能性があります。
• UI ステータス コールバックを使用して、ワンタップが表示されない場合に別の UI を表示します。今後のリリースで UI ステータス コールバックが連携認証情報管理とうまく機能しない可能性があるため、これはおすすめしません。

ITP ブラウザでのワンタップ

インテリジェント トラッキング防止機能（ITP）により、iOS 版 Chrome、Safari、Firefox などの ITP ブラウザでは、通常のワンタップ UX は機能しません。これらのブラウザでは、代わりにウェルカム ページから始まる別の UX が提供されます。

ITP ブラウザのワンタップ UX は、必要に応じて無効にできます。詳しくは、ITP ブラウザでのワンタップ サポートをご覧ください。

注: ITP ブラウザのワンタップ UX は自動ログインをサポートしていません。

Android/macOS/Linux 版 Chrome や Edge など、ITP 以外のブラウザでこの UX を有効にすることはできません。

ユーザーがクリックして離れた場合のプロンプトのキャンセル

デフォルトでは、ユーザーがプロンプトの外側をクリックすると、ワンタップ プロンプトは自動的に閉じます。この動作は必要に応じて変更できます。

パソコンのウェブでは、画面サイズが十分に大きいため、ワンタップ プロンプトを開いたままにすることをおすすめします。

注: [Google でログイン] ボタンのクリックによりポップアップ ウィンドウが開くと、そのボタンと同じページにあるワンタップ UI が閉じます。これは、2 つの [Google でログイン] UX フローが同時にユーザーに表示されるのを防ぐためです。この動作は、上記のキャンセル設定の影響を受けません。

ワンタップ UX の位置を変更する

パソコンのウェブでは、ワンタップ プロンプトの位置を変更できます。ただし、この機能は、今後のリリースの連携認証情報管理でサポートされていないため、おすすめしません。

警告: ワンタップ プロンプトの位置を変更した場合、ワンタップが今後予定されている連携認証情報管理を組み込む際に、今後のリリースでコードや UI の変更が必要になる可能性があります。

ログイン コンテキストを変更する

ワンタップは、ウェブサイトのより大きな UX フローの一部である必要があります。デフォルトでは、ワンタップ UI はログイン コンテキスト内で使用されます。UI の文言に「ログイン」などの特定の文言が含まれています。コンテキスト属性を変更して、別の文言を作成できます。UX フローに最適なワンタップ ヘッダーを選択できます。

コンテキスト
signin	「Google でログイン」
signup	「Google で登録」
use	[Google で使用する]

キーポイント: コンテキストを変更する方法については、ワンタップ ログインのコンテキストを変更するをご覧ください。

ワンタップ UI のステータスをリッスンする

ワンタップは、より大きな UX フローにシームレスに統合するために、UI のステータスが変更されたときに通知できます。ただし、この機能は今後の連携認証情報管理のリリースではサポートされません。

警告: One Tap UI のステータス表示をリッスンする場合、One Tap に連携認証情報管理が組み込まれた今後のリリースでは、コードや UI の変更が必要になる可能性があります。

サブドメイン全体でのワンタップ

デフォルトでは、ワンタップのクールダウンなどのステータスはオリジンごとに追跡されます。ウェブサイトが複数のサブドメインにわたってワンタップ表示する場合は、API コードでそのことを明記する必要があります。

重要なポイント: 詳細については、サブドメイン全体でワンタップ表示するをご覧ください。

静的 HTML ページでのワンタップ

デフォルトでは、GIS ライブラリはウェブページが動的に生成されることを前提としています。HTTP サーバーは、HTML コードを生成するときにユーザーのログイン ステータスを確認します。

• ユーザーがログインしていない場合は、生成されたページにワンタップ HTML コードを含めて、ワンタップをトリガーし、ユーザーがウェブサイトにログインできるようにする必要があります。
• ユーザーがすでにログインしている場合は、生成されたページにワンタップ HTML コードを含めないでください。

この場合、One Tap HTML API コードの追加または削除はウェブサーバーの責任で行います。

One Tap HTML API コードは、静的 HTML コンテンツを大量にホストするウェブサイト向けに設計された別の方法で動作することもできます。静的 HTML ページに One Tap HTML API コードをいつでも含め、ウェブサイトで使用するセッション Cookie 名を指定できます。

• セッション Cookie が存在しない場合、ワンタップ フローがトリガーされます。
• セッション Cookie が存在する場合、ワンタップ フローはスキップされます。

この場合、ワンタップ フローをトリガーするかどうかは、ウェブページにワンタップ HTML API コードが存在するかどうかではなく、セッション クッキーのステータスによって制御されます。

キーポイント: 詳しくは、Cookie を使用してワンタップ表示を切り替えるをご覧ください。

キーポイント: [Google でログイン] ボタンは通常、コンテンツ ページではなくメインのログイン ダイアログで使用されるため、Cookie を使用してレンダリングを切り替えることはできません。

サーバーサイドの統合

ワンタップ、自動ログイン、または「Google でログイン」ボタンの UX フローが完了すると、ID トークンが発行され、ウェブサイトと共有されます。ユーザーを認証するには、ID トークンを受け取って検証するために、サーバーサイドでいくつかの変更が必要です。

UX に関する注意事項

通常、サーバーサイドでレスポンスを処理するには、独自のオリジンに HTTP エンドポイントを追加する必要があります。次の要因が、結果として得られる UX に影響する可能性があります。

• ワンタップまたは「Google でログイン」がトリガーされたかどうか。
• HTML API と JavaScript API のどちらを使用するか。
• レスポンスの処理に ログイン URI と JavaScript コールバック関数のどちらを使用するか。

実際の UX は次のとおりです。

1. [Google でログイン] ボタンのリダイレクト UX モードの場合:

   • HTML API と JavaScript API のどちらを使用する場合でも、ログイン URI を設定する必要があります。ユーザーはすでにウェブページからリダイレクトされているため、JavaScript コールバック関数を使用してレスポンスを処理することはできません。
   • UX の概要: [Google でログイン] ボタンをクリックすると、セッションの選択と承認を行う Google UI にフルページでリダイレクトされます。完了すると、指定したログイン URI にフルページの POST が送信されます。

2. ワンタップまたは [Google でログイン] ボタンのポップアップ UX モードで、JavaScript API が使用されている場合、または HTML API が使用されていて JavaScript コールバック関数が指定されている場合:

   • 認証レスポンスは JavaScript コールバック関数に渡されます。
   • UX の概要: ウェブページの上にワンタップ プロンプトまたはポップアップ ウィンドウが表示されます。ユーザーがプロンプトまたはポップアップ ウィンドウでセッションの選択と承認の UX を完了すると、JavaScript コールバック関数がレスポンスを受け取ります。その後の UX は、コールバック関数がレスポンスをサーバーに送信する方法によって決まります。
   キーポイント: ウェブページを再読み込みせずに認証するには、JavaScript コールバック関数で認証レスポンスを受信し、XmlHttpRequest を使用してサーバーに送信するのが一般的です。
   キーポイント: 独自のセキュリティ対策を適用するには、JavaScript コールバック関数で認証レスポンスを受信し、ウェブサイトに必要な他のパラメータとともに送信します。

3. それ以外の場合（ログイン URI を使用する HTML API の場合）:

   • 認証レスポンスはログイン URI に送信されます。
   • UX の概要: ウェブページの上にワンタップ プロンプトまたはポップアップ ウィンドウが表示されます。ユーザーがプロンプトまたはポップアップ ウィンドウでセッションの選択と承認の UX を完了すると、指定したログイン URL にフルページの POST 送信を使用して認証レスポンスが送信されます。

ワンタップ レスポンスと [Google でログイン] ボタンのレスポンスは、一貫した方法で送信することをおすすめします。

セキュリティ上の考慮事項

クロスサイト リクエスト フォージェリ攻撃を防ぐには、

• Google Identity Service クライアント JavaScript ライブラリによってトリガーされる投稿送信の場合は、組み込みの double-submit-cookie パターンを使用できます。詳しくは、サーバーサイドで Google ID トークンを検証するをご覧ください。
• XmlHttpRequest を使用して独自のオリジンに送信する場合は、カスタム HTTP ヘッダーや、セキュリティ チームが承認したその他のセキュリティ対策を使用できます。

認証レスポンスでID トークンを検証するには、プラットフォーム用の Google API クライアント ライブラリまたは汎用 JWT ライブラリを使用することを強くおすすめします。

よくある質問（FAQ）

• ワンタップと「Google でログイン」ボタンはウェブビューで使用できますか？

  いいえ。セキュリティ上の懸念から、Google セッションをウェブビューに追加しないでください。そのため、Google セッションが存在しないため、ウェブビューでは GIS が無効になります。

• 独自の「Google でログイン」ボタンを使用できますか？いいえ。OAuth サーバーサイド フローまたは以前のバージョンの Google ログイン JavaScript ライブラリでは、依存する事業者はログイン ブランディング ガイドラインを使用して、独自のバージョンの Google ログイン ボタンを作成できました。

  ただし、[Google でログイン] ではこの機能が削除されています。「Google でログイン」ボタンはすべて、Google Identity Services JavaScript ライブラリで生成する必要があります。この変更には 2 つの理由があります。

  • 一部の信頼できる第三者がガイドラインに準拠しなかったため、ウェブサイト間で [Google でログイン] ボタンが統一されていません。
  • ライブラリで生成することで、ログイン ブランディング ガイドライン自体が変更されても変更する必要はありません。

  このルールを適用するため、JavaScript ライブラリはボタンをレンダリングする API のみを公開し、ログインフローを開始する API は公開しません。

• ウェブサイトでワンタップのみ有効にして、[Google でログイン] ボタンを有効にしていない場合はどうなりますか？

  ウェブサイトでは、ワンタップと [Google でログイン] ボタンの両方を使用することをおすすめします。指数関数的なクールダウンのため、ワンタップが毎回表示されないことがあります。ユーザーが Google アカウントでウェブサイトにログインしたい場合は、メインのログイン ダイアログに移動し、[Google でログイン] ボタンでログインできます。[Google でログイン] ボタンを使用してログインに成功すると、ワンタップのクールダウン ステータスがクリアされ、次回のログイン時にワンタップが表示されるようになります。Google の他のボタンフローでは、ワンタップ クールダウンのステータスを消去できません。これは、異なる JavaScript バイナリにあるためです。

  ウェブサイトでワンタップのみ有効にして、[Google でログイン] ボタンを有効にしていない場合、指数関数的なクールダウン ステータスが時間内に消去されないため、ワンタップ フローのパフォーマンスが低下する可能性があります。

• HTML API コードはいつ解析されますか？HTML API コードを後で変更できますか？

  Google Identity Services JavaScript ライブラリは、JavaScript ライブラリの読み込みイベントまたは DomContentLoaded イベントのどちらか遅い方で HTML API コードを解析して実行します。

  • JavaScript ライブラリの読み込み時に DomContentLoaded イベントがトリガーされると、HTML API コードが解析され、すぐに実行されます。
  • それ以外の場合は、JavaScript ライブラリが DomContentLoaded イベントのリスナーを追加します。トリガーされると、リスナーは HTML API コードを解析して実行します。

  また、HTML API コードの解析と実行は別物です。

  • 解析と実行後に HTML API コードに加えた変更はすべて無視されます。
  • デベロッパーが解析プロセスまたは実行プロセスをトリガーする API はありません。
  ヒント: 上記の動作が要件を満たさない場合は、JavaScript API を使用してください。