「Google でログイン」の実装に関するベスト プラクティス

Google でログイン

はじめに

Google でログイン(SiwG)は、ユーザーがアプリやウェブサイトにすばやく安全にログインできる方法です。適切に実装することで、ユーザー登録プロセスが簡素化されるだけでなく、アプリケーションのセキュリティも強化されます。このドキュメントでは、ウェブ、Android、iOS の各プラットフォームで「Google でログイン」を統合するためのベスト プラクティスについて説明します。このドキュメントでは、認証についてのみ説明します。認可については、このドキュメントでは説明しません。

統合マイルストーンのチェックリスト

このチェックリストは、Google でログインの統合プロセスをガイドする概要レベルのロードマップです。初期設定から本番環境のリリースまで、主要なフェーズに分かれています。このリストを使用して進捗状況を把握し、リンクをクリックして各マイルストーンの詳細なガイダンスに移動します。

フェーズ 0: スタートガイド(省略可)

実践的なステップバイステップのデベロッパー Codelab で統合をスムーズに開始できます。

ウェブ: ワンタップGoogle でログインボタンの Codelab を完了して、基本的なウェブ統合を構築します。

Android: Android Codelab を完了して、Android の Credential Manager の基礎を学習します。

iOS: iOS SDK の概要については、iOS の Codelab を完了してください。

フェーズ 1: Google Cloud プロジェクトとブランドの構成

プロジェクトが最初から成功するように設定します。

さまざまな環境ブランドに対応するように Google Cloud プロジェクトを構造化します。

必要なブランディングとサポート情報をすべて入力して、OAuth 同意画面の設定を完了します。

各プラットフォーム(ウェブ、Android、iOS)に適切な OAuth クライアント ID タイプを作成します。

フェーズ 2: コア開発: フロントエンドとバックエンド

安全なサーバー ロジックとプラットフォーム固有のユーザー エクスペリエンスを構築します。

フロントエンド開発では、次のことを行う必要があります。

一般的なユーザー エクスペリエンス(UX)のベスト プラクティスを確認して適用し、ユーザーの定着と信頼を最大限に高めます。

ウェブ: 公式の JavaScript ライブラリを使用して、ボタンフローとワンタップ フローの両方を統合します。

Android: 公式の Android SDK を使用して統合します。

iOS: 公式の iOS SDK を使用して統合します。

バックエンド開発では、次の点に注意してください。

Google ID トークンの安全なバックエンド検証を実装します。

システム内で一意の永続的なユーザー ID として sub クレームを使用します。

該当する場合は、認証と認可のスコープの分離を計画します。

フェーズ 3: セキュリティ強化と本番環境でのリリース

統合が安全で、コンプライアンスに準拠しており、本番環境で使用できることを確認します。

セキュリティのベスト プラクティスを確認して実装します。

リリース前に OAuth アプリの確認プロセスを完了します。

ユーザー アカウントの削除時に、アプリケーションがトークンの取り消しを正しく処理することを確認します。

一般的なベスト プラクティス(すべてのプラットフォーム)

これらのプラクティスは、開発対象のプラットフォームに関係なく適用されます。デベロッパーは、OAuth 2.0 に関する一般的なポリシーも確認して、完全な準拠を確保する必要があります。

このセクションでは、セキュリティとブランディングのコンプライアンスを確保するために Google Cloud プロジェクトを構成し、OAuth クライアントを設定するためのベスト プラクティスについて説明します。

  • テストと本番環境に個別のプロジェクトを使用する

    Google のポリシーの一部は本番環境のアプリにのみ適用されるため、開発環境、ステージング環境、本番環境など、さまざまなデプロイ環境用に Google Cloud コンソールで個別のプロジェクトを作成する必要があります。詳しくは、こちらのページをご覧ください。

  • ブランドまたはドメインごとに個別のプロジェクトを使用する

    組織で複数のアプリケーションを管理しており、それぞれに異なるブランドがある場合は、ブランドごとに専用の Google Cloud プロジェクトが必要です。同意画面に表示されるユーザー向けの情報(アプリケーション名、ロゴ、サポートメール、利用規約とプライバシー ポリシーへのリンクなど)は、プロジェクト レベルで構成されます。つまり、1 つのプロジェクト内で作成されたすべての OAuth クライアント ID は、同じブランディングを共有します。各ブランドに独自のプロジェクトを割り当てることで、ユーザーが使用している特定のアプリケーションの正しいブランディングと法的情報を確認できます。

  • 一般的なサポートのメールアドレスを提供する

    ユーザー サポートのメールアドレスは、OAuth 同意画面に公開されます。プロフェッショナルな対応を維持し、継続性を確保するため、常に一般的なサポート メール(例: support@yourdomain.com)を、個々の従業員のメールアドレスの代わりに Google Cloud プロジェクトの OAuth 同意画面の設定に追加します。詳しくは、こちらのページをご覧ください。

  • プラットフォームごとの OAuth クライアント

    アプリが実行されるプラットフォーム(ウェブ、Android、iOS)を、すべて同じ Google Cloud プロジェクト内で実行します。各プラットフォームで正しいクライアント タイプを使用することが重要な理由は、主に次の 2 つです。

    • セキュリティの強化: 各クライアント タイプで、プラットフォーム固有のセキュリティ機能が有効になります。たとえば、Android クライアントはパッケージ名と署名証明書でロックダウンできるため、クライアント ID の不正使用を防ぐことができます。
    • 適切な機能: アプリケーションが、Android の Credential Manager や iOS 向けの Google でログイン SDK などのプラットフォーム固有の SDK や機能と正しく統合されていることを確認します。

    この構造により、ユーザー エクスペリエンスも簡素化されます。同意は Google Cloud プロジェクト レベルで処理されるため、ユーザーはすべてのプラットフォームでアプリケーションに対して一度だけ同意すれば済みます。詳しくは、公式の OAuth 2.0 ポリシーをご覧ください。

  • OAuth アプリの検証を完了する

    本番環境アプリの名前とロゴを表示するには、確認を受ける必要があります。確認の種類は、ユーザーにリクエストするデータによって異なります。

    • Google でログイン認証スコープemailprofileopenid)のみをリクエストするため、よりシンプルなブランド認証の対象となります。このプロセスは通常、より迅速に行われ、ブランドのアイデンティティの確認に重点が置かれます。

    リリース スケジュールを立てるうえで、Google はさまざまな確認タイプとその想定される審査時間の内訳を提供しています。確認ポリシーについて詳しくは、OAuth アプリの確認に関するヘルプセンターをご覧ください。

セキュリティとトークンの処理

このセクションでは、デベロッパーがバックエンド サーバーに実装する必要があるランタイム要件とセキュリティ対策について説明します。

  • Google ID トークンをバックエンドと統合する

    • ID トークンを検証する: バックエンド サーバーで Google ID トークンの整合性を常に検証します。クライアントから送信されたトークンだからといって、信頼してはいけません。この検証には Google API クライアント ライブラリを使用することをおすすめします。詳細については、サーバーサイドで Google ID トークンを検証するをご覧ください。
    • sub クレームを使用する: Google ID トークンsub フィールドは、すべての Google アカウントで一意かつ安定しており、再利用されることもないため、ユーザーの識別子としてのみ使用します。sub フィールドを保存し、アカウント管理システムでユーザーに関連付ける必要があります。ID トークンのメールアドレスを使用して、ユーザーが既存のアカウントを持っているかどうかを確認できますが、Google アカウントには異なる時点で複数のメールアドレスを設定できるため、メールアドレスを識別子として使用しないでください。
  • アカウント削除時にトークンを取り消す

    Google でログインするユーザーに対して、Google アカウントをアプリから切断する機能を提供することを強く推奨します。ユーザーがアカウントの削除を選択した場合は、アプリが取得したすべてのアクセス トークンと更新トークンを取り消す必要があります。

    クライアントサイドのトークン取り消しの詳細については、ウェブAndroidiOS のドキュメントをご覧ください。サーバーサイドの取り消しについては、ウェブサーバー アプリケーションに OAuth 2.0 を使用するをご覧ください。

  • 認証と認可を分離する

    Google でログイン SDK は、認証に必要なスコープのみをリクエストします。アプリケーションで他の Google サービス(Google カレンダーやドライブなど)にアクセスする必要がある場合は、それらの権限を個別にリクエストする必要があります。また、ユーザーがそれらの権限を必要とする操作を行おうとしている場合にのみリクエストする必要があります。詳しくは、認証と承認のタイミングを分離するをご覧ください。

  • セキュリティに関するベスト プラクティス

    安全な統合を行うには、Google API クライアント ライブラリを使用して、バックエンド サーバーで常に ID トークンを検証します。さまざまな脅威に対する包括的な保護を実現するには、セキュリティ バンドルクロスアカウント保護機能(RISC)を実装します。また、iOS アプリの場合は、リクエストが正規のアプリから送信されたものであることを確認するために、App Check を統合することを強くおすすめします。

ユーザー エクスペリエンス(UX)

このセクションでは、ユーザー向けの要素とログイン/登録フローの最適化に焦点を当てます。

  • ボタンを目立つように表示する: [Google でログイン] ボタンは、ログイン ページと登録ページで明確に表示され、アクセスできるようにする必要があります。

  • ブランド ガイドラインに準拠する: 一貫性があり信頼できるユーザー エクスペリエンスを実現するため、Google の公式ブランドのログインボタンを使用します。公式の 「Google でログイン」のブランド ガイドラインを確認してください。

  • スムーズな登録: 新規ユーザー向けに、Google でログインのフローが初めて成功したときに、アカウントを自動的に作成するか、新しいアカウント作成フローにユーザーを誘導します。バックエンドで、指定された sub ID のユーザーが存在するかどうかを確認します。存在しない場合は、新しいアカウントを作成します。これにより、登録の手間を最小限に抑えることができます。

  • ログインの簡素化: リピーター ユーザーの場合は、sub ID を使用して既存のアカウントを特定し、認証します。ウェブAndroid の自動ログインなどの機能を実装して、ユーザーがアプリにすばやく安全に戻れるようにします。

  • ソーシャル ログイン方法の管理: ユーザー設定に [リンク済みのアカウント] セクションが追加され、ユーザーはさまざまなソーシャル ログイン方法(Google など)を管理できます。

    • リンク: 他の方法(ユーザー名とパスワードなど)を使用している既存のユーザー向けに「Google でログイン」ボタンを提供します。このボタンをクリックすると、Google アカウントを既存のプロフィールにリンクするための認証フローが開始されます。

    • リンクの解除: アカウントの接続を解除するオプションを提供します。この処理を完了するには、トークンを取り消し、データベースから Google の関連付けを削除する必要があります。

Android の実装(アプリとゲーム)

標準の Android アプリ

Android の実装では、認証情報マネージャーを使用する必要があります。これは、ユーザー認証情報を処理するうえで推奨されるアプローチであり、Android で統一された安全で一貫性のあるログイン エクスペリエンスを提供します。

実装には Android の OAuth クライアント ID を使用します。他のプラットフォーム(ウェブ、iOS など)ですでに「Google でログイン」を実装している場合は、同じ Google Cloud プロジェクトで新しい OAuth クライアント ID(Android タイプ)を作成する必要があります。

実装フロー

堅牢な実装には、認証情報マネージャーのボトムシート UI と「Google でログイン」ボタンの両方を含める必要があります。

  • ボトムシート: ユーザーがログイン画面にアクセスしたときに、認証情報マネージャーによって表示される、デベロッパー主導の低摩擦のプロンプトです。
  • [Google でログイン] ボタン: ユーザーがタップして開始できる、明示的なユーザー開始のログインフローです。
  • 正確な Google Cloud プロジェクトの構成が不可欠です。これには、正しいタイプの OAuth クライアント ID を作成し、アプリの SHA-1 証明書のフィンガープリントなどの詳細情報を指定する必要があります。正しくセットアップするには、公式の Android デベロッパー ガイドに沿って正確に操作してください。

ユーザーがボトムシートを閉じたり、設定で無効にしたりする可能性があるため、常にボタンフローを含める必要があります。ボタンを使用すると、常にログイン プロセスを開始できます。

プレースメント戦略

  • [Google でログイン] ボタン:

    • 場所: 専用の登録ページまたはログインページに [Google でログイン] ボタンを表示します。
    • 視認性: ユーザー名とパスワードのフィールドや他のソーシャル ログイン プロバイダなど、他のログイン方法と並べて目立つ場所に配置します。
  • 認証情報マネージャーのボトムシート:

    • トリガー: ログインページが起動したとき、またはアプリが起動したときに、ボトムシートが自動的に呼び出されるようにします。ユーザーがボタンをタップしたときにトリガーされるべきではありません。
    • 自動ログイン: リピーター ユーザーの場合は、認証情報マネージャーで自動ログイン オプションを有効にすることを強くおすすめします。これにより、リピーター(以前に同意済み)は操作なしでアプリに再ログインできます。

Android ゲーム

Android ゲームの場合、Credential Manager は推奨されるアプローチではありません。代わりに、ゲーム デベロッパーは、Google でログインを使用したクロス プラットフォームの Google ID に重点を置いた Google Play ゲームサービス(PGS)アプローチを使用する必要があります。詳細については、Google でログインを使用したクロス プラットフォームの Google ID のドキュメントをご覧ください。

iOS の実装

公式の Google ログイン SDK を使用する

iOS アプリの場合は、公式の Sign in with Google for iOS and macOS SDK を使用する必要があります。このライブラリは、Google でログインを統合する最も安全でユーザー フレンドリーな方法を提供します。

実装には iOS 用の OAuth クライアント ID を使用します。他のプラットフォーム(ウェブ、Android など)ですでに「Google でログイン」を実装している場合は、同じ Google Cloud プロジェクトで新しい OAuth クライアント ID(iOS タイプ)を作成する必要があります。

[Google でログイン] ボタンを追加する

  • 配置: 登録ページとログイン ページの両方で、アプリのログイン ビューに [Google でログイン] ボタンを追加します。ユーザー名とパスワードのフィールドや他のソーシャル ログイン プロバイダなど、他のログイン方法と並べて目立つように配置します。
  • 推奨コンポーネントを使用する: SDK で提供される公式のボタン コンポーネントを SwiftUI と UIKit の両方で使用します。これらのコンポーネントは、Google のブランディング ガイドラインに準拠したボタンを自動的に生成します。ボタンを表示する際は、この方法をおすすめします。

App Check でセキュリティを強化する

OAuth 2.0 クライアントに対するリクエストが正規のアプリから送信されたものであることを確認することで、バックエンド リソースを不正使用から保護します。App Check は、証明書プロバイダを使用して、リクエストがアプリの正規の改ざんされていないインスタンスから送信されたものであることを確認し、そうでないリクエストを拒否します。詳しくは、iOS での Google ログイン用の App Check をご覧ください。

ウェブでの実装

ウェブサイトとウェブ アプリケーションに関するガイダンス。

公式の Google ログイン JavaScript ライブラリを使用する

ウェブ実装の場合は、公式の Google でログイン JavaScript ライブラリを使用する必要があります。これは、ウェブ用の Google の ID ライブラリの最新世代であり、ボタンワンタップの両方の機能が含まれています。

実装には ウェブ用の OAuth クライアント ID を使用します。他のプラットフォーム(Android、iOS など)ですでに「Google でログイン」を実装している場合は、同じ Google Cloud プロジェクトで新しい OAuth クライアント ID ウェブタイプを作成する必要があります。

ボタンフローとワンタップ フローの両方を実装する

「Google でログイン」ボタンとワンタップ ログインの両方を実装することをおすすめします。

  • [Google でログイン] ボタン: これは、ユーザーが明示的に開始するログイン/登録フローです。
  • One Tap: ユーザーに負担をかけず、中断を最小限に抑えたサインインまたは登録のプロンプトを表示します。
  • 両方の実装で ウェブに同じ OAuth クライアント ID を使用します。

ボタンは常にプライマリ ログイン オプションとして含める必要があります。ユーザーは Google アカウントの設定でワンタップを閉じるか無効にできますが、ボタンは常に利用可能であるため、ユーザーがログインできなくなることはありません。

プレースメント戦略

  • [Google でログイン] ボタン:

    • 場所: 専用の登録ページまたはログインページに、カスタマイズされた [Google でログイン] ボタンを表示します。
      • すべてのサイトに最適なパターン(リダイレクトポップアップなど)は存在しません。ウェブ デザイン チームまたは UX チームは、登録とログインの両方の完了率を最大化するために、これらのフローをテストして最適化する必要があります。
    • 視認性: ユーザー名とパスワードのフィールドや他のソーシャル ログイン プロバイダなど、他のログイン方法と並べて目立つ場所に配置します。
    • 確認: 最適な設定とパフォーマンスについては、[Google でログイン] ボタンに関する考慮事項のセクションをご覧ください。
  • One Tap プロンプト:

    • 場所: 個々の商品ページ、記事ページ、ホームページなど、ウェブサイトの複数のページにワンタップ プロンプトを表示します。One Tap の主なメリットは、ユーザーが現在のページから移動することなくログインしたり、アカウントを作成したりできることです。
    • 自動ログイン: リピーター ユーザーに対しては、ワンタップで自動ログイン オプションを有効にすることを強くおすすめします。これにより、リピーター(以前に同意済み)は操作なしでアプリに再ログインできます。
    • 確認: 最適な構成とパフォーマンスについては、ワンタップの考慮事項のセクションをご覧ください。