統合に関する考慮事項

この手順ガイドは、統合に関するすべての主な問題に関する意思決定に役立ちます。

概要ページの「Google でログイン」

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

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

   「Google でログイン」が機能するためには、ブラウザにアクティブな Google セッションが存在する必要があります。ワンタップと自動ログインは、ユーザーがウェブページを読み込む前に Google にログインした場合にのみトリガーされます。この手順は、[Google でログイン] ボタンのフローでは任意です。ボタンが押されると、ユーザーは Google へのログインを求められるためです。

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

2. ユーザーは、[ワンタップ]、[自動ログイン]、[Google でログイン] の各ボタンが埋め込まれているウェブページをブラウジングします。

   キーポイント: コード生成ツールを使用すると、ワンタップ、自動ログイン、「Google でログイン」ボタンをウェブページに埋め込むコードを簡単に生成できます。

3. ユーザーは、ワンタップ、[Google でログイン] ボタン、および後続の UX フローを使用して、次のことを行います。

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

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

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

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

   

   承認されると、Google はその決定を記録して、次回は同意ページをスキップできるようにします。

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

   ID トークンをクライアント側の JavaScript コールバック ハンドラに返す目的は、ユーザーが 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 を使用して、返された認証情報をサーバーに送信すると、デフォルトの送信後のページの再読み込みを回避できます。

  キーポイント: ウェブページを再読み込みせずに認証するには、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 の両方）に重複しない部分がないか、確認してください。次の点にご注意ください。

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

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

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

• revoke
• cancel
• disableAutoSelect
• storeCredential

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

ポップアップとリダイレクト

OAuth 2.0 仕様では HTTP リダイレクトを考慮していますが、ポップアップ ダイアログのレンダリングに関するガイダンスがありません。特に PC ウェブでは、ポップアップの UX によってエンドユーザーの UX が向上する可能性があります。ユーザーがサードパーティのページからリダイレクトされることがなく、ダイアログのようなポップアップ ウィンドウが状況に応じて権限付与を行えるためです。

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

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

キーポイント: 「Google でログイン」ボタンは、ポップアップの UX に対応しています。

「Google でログイン」ボタンのリダイレクト フローと OAuth リダイレクト フローには、いくつかの違いがあります。

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

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

キーポイント: 「Google でログイン」ボタンのリダイレクト フローと OAuth リダイレクト フローには違いがあります。

ボタンのカスタマイズ

独自ボタンの使用はサポートされていません。ボタンフローをプログラムで開始する API はありません。

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

ボタン レンダリング API を使用すると、「Google でログイン」ボタンのデザインをカスタマイズできます。コード生成ツールを使用してインタラクティブなボタンをデザインすることをおすすめします。JavaScript API を使用する場合でも、最初に HTML コードを生成してから、そのコードを JavaScript API の対応するフィールドにコピーできます。

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

同じウェブページに複数のボタンを配置できます。コード生成ツールは、一度に 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 リクエストが Google に送信され、ボタンの iframe が読み込まれます。この iframe にはパーソナライズされた情報が含まれている場合があります。ボタンの iframe が読み込まれると、インライン バージョンのボタンは削除されます。

「Google でログイン」ボタンのフローボタンの表示の遅延を最小限に抑えるためのベスト プラクティスを以下に示します。

• Google Identity Services JavaScript ライブラリをできるだけ早く読み込みます。特にモバイルウェブでは、他の大きなライブラリよりも先に JavaScript ライブラリを読み込むことをおすすめします。

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

  キーポイント: Google Identity Services JavaScript ライブラリをできるだけ早く読み込んで、[Google でログイン] ボタンの表示のレイテンシを最小限に抑えてください。

ワンタップに関する考慮事項

自動ログイン

キャンセル可能な自動ログインには、次のメリットがあります。

• 1 つのユーザー アクションを保存することで、ログイン率が向上する場合があります。
• サポートが終了した Google ログイン JavaScript ライブラリですでに提供されていたサイレント ログインとは異なり、自動ログインが発生すると、ユーザーには常になんらかの UI が表示され、ウェブサイトにログインした理由や方法を確認できます。ユーザーは必要に応じて解約することもできます。
• ユーザーが以前に使用していたアカウントが自動的に選択されるため、ユーザーがウェブサイトで重複するアカウントを作成できなくなる可能性があります。

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

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

HTML API では、ページ読み込み時にワンタップが常に表示されます。JavaScript

ワンタップ UI を表示するタイミングを制御できます。なお、以下で説明するような理由から、ワンタップ UI は API の呼び出し後に必ず表示されるとは限りません。

• ブラウザに有効な Google セッションがありません。
• すべてのアクティブな Google セッションがオプトアウトされます。
• クールダウンが行われています。

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

推奨

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

非推奨例

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

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

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

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

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

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

ユーザーが閉じた場合にプロンプトをキャンセルする

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

画面サイズが十分な大きさであるため、PC ウェブではワンタップ プロンプトを開いたままにしておくことをおすすめします。

注: 「Google でログイン」ボタンのクリックによってポップ ウィンドウが開いた場合は、そのボタンの同じページのワンタップ UI が閉じ、同時に 2 つの「Google でログイン」UX フローがユーザーに提示されないようにします。この動作は、前述のキャンセル設定の影響を受けません。

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

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

警告: ワンタップ プロンプトの位置を変更すると、予想されるフェデレーション認証情報管理がワンタップに組み込まれる今後のリリースで、コードまたは UI の変更が必要になることがあります。

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

ワンタップは、ウェブサイトのより大きな UX フローに組み込む必要があります。デフォルトでは、ワンタップ UI はログイン コンテキストで使用されます。UI の言語には、「ログイン」などの特定の表現が含まれています。コンテキスト属性を変更して、別の言い回しのセットを作成できます。自分の UX フローに最適なワンタップ ヘッダーを 1 つ選択できます。

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

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

ワンタップ UI ステータスでのリッスン

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

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

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

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

キーポイント: 詳しくは、サブドメイン間でワンタップを表示するをご覧ください。

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

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

• ログイン中のユーザーがいない場合は、結果のページにワンタップの HTML コードを含めて、ユーザーがウェブサイトにログインできるようにワンタップをトリガーする必要があります。
• ユーザーがすでにログインしている場合、表示されるページにワンタップの HTML コードを含めることはできません。

この場合、ワンタップ HTML API コードの追加と削除はウェブサーバーが行います。

One Tap HTML API コードは別の方法でも機能します。これは、多くの静的 HTML コンテンツをホストするウェブサイト用に設計されています。静的 HTML ページにワンタップ HTML API コードを常に含めて、ウェブサイトで使用されるセッション Cookie 名を指定できます。

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

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

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

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

サーバーサイドの統合

ワンタップ、自動ログイン、または「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）

• WebView で [ワンタップ] ボタンと [Google でログイン] ボタンを利用できますか？

  いいえ。セキュリティ上の懸念から、ユーザーは Google セッションを WebView に追加しないでください。このように、WebView では 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 を使用してください。