ある Google OAuth クライアント ID は、Google が「〜」で終わる文字列として表示する公開アプリの識別子です。 .apps.googleusercontent.comこれは、 Google Cloud Console 内の Google Auth Platform > クライアント または APIとサービス > 認証情報 で作成・管理します。この値によって、Google はどの登録済みアプリが Sign in with Google を開始したか、または OAuth トークンをリクエストしているかを判断します。
Google Sign-Inはすぐに統合できるはずだったのに、気づけば認証情報の画面を前に「なぜあるアプリタイプではクライアントシークレットが発行され、別のタイプではされないのか」と悩んでいるのではないでしょうか。Capacitor、Ionic、Electron、あるいはWebとネイティブが混在するスタックで開発しているなら、この混乱はよくあることです。
多くのガイドが飛ばしてしまう部分こそ、実際の実装が壊れる原因です： Google Client IDはプラットフォームごとに異なります、またWeb以外のアプリタイプでは多くの場合、 設計上、 クライアントシークレットは発行されません。フローにシークレットを無理やり組み込もうとして誤った認証情報を作成すると、本来よりデバッグが難しい壊れたOAuth設定になりがちです。
目次
- 前提条件: OAuth 同意画面
- OAuth 2.0 クライアント ID の作成方法
- 既存のクライアント ID の確認方法
- クライアント ID とクライアント シークレットの違い
- Google Client IDとは？
- プラットフォーム別のクライアントID設定
- Google API 認証情報の保護
- よくあるクライアントIDエラーのトラブルシューティング
- よくある質問
前提条件: OAuth 同意画面
Google で OAuth クライアントを作成する前に、プロジェクトでアプリを Google Auth に登録する必要があります。Google は、次の画面で完了を促します: Google Auth Platform > クライアント を初めて開くとき。
一般的な手順:
- 開く Google Cloud Console で、サインインを管理するプロジェクトを選択します。
- 以下に移動します： Google Auth プラットフォーム (または API とサービス > OAuth 同意画面 （古いナビゲーションの場合）。
- 選択: 外部 または 内部 ユーザータイプを選択し、アプリ名、サポート用メールアドレス、開発者の連絡先を入力します。
- アプリがリクエストするスコープを追加します（基本的なサインイン用なら、
emailとprofile一般的なもので問題ありません）。 - 保存して、アプリの登録が完了するまで同意画面のワークフローを進めてください。
この画面で設定するアプリケーション名は、Google の権限確認プロンプトに表示されます。内部用のコードネームではなく、ユーザーがインストールしたアプリ名と一致させる必要があります。
OAuth 2.0 クライアント ID の作成方法
Google はこのフローについて、 OAuthクライアントの管理 ヘルプページ。次の2つのエントリポイントはどちらも利用できます：
- Google Auth Platform > クライアント （その後 クライアントを作成)
- APIとサービス > 認証情報 （その後 資格情報の作成 > OAuth クライアント ID)
まず Cloud プロジェクトを選択または作成してください。認証資格情報を無関係なプロジェクトに分散させないでください。
Web アプリケーション クライアント
ブラウザアプリおよび Web クライアント ID 多くのモバイル SDK がサーバーのオーディエンスとして期待しています。
- クリック クライアントを作成 (または OAuth クライアント ID を Credentials から作成)
- 選択: Web アプリケーション をアプリケーションタイプとして選択。
- 設定 承認済みの JavaScript 生成元 をサインイン UI を実行する各オリジンに追加します（スキーム、ホスト、ポートは完全に一致させる必要があります）。
http://localhost:<port>はローカル開発に使用します。Google のルールにより、本番環境のオリジンは localhost 以外 HTTPS を使用する必要があります。 - 設定 承認済みリダイレクト URI Google がリダイレクトして戻る際に、サーバーまたは SPA が使用する各コールバック URL に追加してください。
- クリック 作成します。 クライアントID をコピーし、 クライアントシークレット を安全に保管してください。Google はシークレットを一度しか表示しない場合があります。
Capacitor ハイブリッドアプリでは、ネイティブ SDK を通じたサインインであっても、Web クライアント ID がトークン検証の基盤となることがよくあります。 Capacitor を使用した Google サインイン方法 を参照して、モバイル全体の接続設定を確認してください。
Android クライアント (パッケージ名と SHA-1)
Android の OAuth クライアントは、Google Sign-In をあなたの パッケージ名 および SHA-1 署名証明書に紐付けます。
-
クリック クライアントを作成 を選択します Androidでは.
-
入力してください パッケージ名 アプリから（例：
com.example.app、一致するapplicationIdGradle 内）。 -
取得する SHA-1 証明書フィンガープリント テスト対象の build に署名する keystore について:
keytool -list -v -keystore path-to-debug-or-production-keystore -alias your-key-aliasGoogle によると、デフォルトの debug keystore のパスワードは多くの場合
androidまた、パスは通常~/.android/debug.keystore. -
SHA-1 をフォームに貼り付けてクリック: 作成します.
-
Android をコピー クライアントID。Google は通常、このタイプには 決して client secret を発行しません。
アプリが Google Play にある場合は、次も登録してください: Play App Signing Play Console の SHA-1 アプリの整合性. Play はアップロード用 keystore とは別のキーでリリースに再署名します。
iOS クライアント (Bundle ID)
- クリック クライアントを作成 を選択します iOSと.
- 入力してください Bundle ID Xcode から（〜と同じ値
CFBundleIdentifierにおけるInfo.plist、例えばcom.example.app). - 必要に応じて追加 App Store ID と チームID Googleから要求されたときに使用します。
- クリック 作成します そしてiOSの...をコピーします クライアントID.
このクライアントをネイティブiOS Google Sign-In、または...と一緒に使用します @capgo/capacitor-social-login Capacitor で Apple と Google のプロバイダーを設定するときに使用します。
クリックしながらUIを比較したいなら、このウォークスルーが視覚的な参考になります：
既存のクライアント ID の確認方法
作成後、開いてください Google Auth Platform > クライアント または APIとサービス > 認証情報。各行には、OAuth 2.0 クライアント ID が名前とタイプで表示されます。クライアントを開いて、その クライアントID 文字列をコピーします（xxxx.apps.googleusercontent.com). Webクライアントも表示します クライアントシークレット 同じ詳細ページで管理できます。
同意画面は単なる飾りではありません。信頼境界の一部です。ユーザーが見るのはアプリケーション名で、プロジェクトの内部ニックネームではありません。
クライアント ID とクライアント シークレットの違い
| 認証情報 | 表示対象 | 一般的な用途 |
|---|---|---|
| クライアントID | 公開用。アプリやフロントエンドに埋め込んでも安全です。 | すべての OAuth フローで、アプリを Google に識別させるための ID です。 |
| クライアントシークレット | 機密情報。サーバーまたはCI専用。 | code からトークンへの交換時に、バックエンドが Web OAuth クライアントを所有していることを証明します。 |
Google の分類では、 Web アプリケーション サーバー上で動作するクライアントは、 プライベート シークレットを使用する可能性があるクライアントとされます。 Androidでは, iOSと、およびその他の インストール クライアントは パブリック クライアントです。APKやIPAに含まれるものはユーザーがすべて抽出できるため、Googleは意図的にシークレットを省略しています。
シークレットを取得するためだけに、モバイルアプリ用のWebクライアントを作成しないでください。この不一致により、 invalid_clientDEVELOPER_ERROR や、後で混乱を招くトークンオーディエンスエラーが発生します。
Google Client IDとは？
ある Google OAuth 2.0 クライアントID は、Googleの認証システムにおけるアプリケーションの公開識別子です。Googleは、Google認証エンドポイントからアクセストークンをリクエストする際のアプリケーションの一意なユーザー名だと説明しており、トークン交換時にアプリの身元を検証するOAuthフローで使われるため、API キーとは異なると述べています。詳しくは Google CloudのOAuthクライアントドキュメント.
次のように考えてください： Google クライアントID アプリの課題と同様に 公開ユーザー名.
これはGoogleに「このリクエストは登録済みのこのアプリケーションから送信されています」と伝えます。サインイン、同意、トークン交換、アプリがユーザーに代わって操作するあらゆるフローで重要です。クライアントIDは、アプリとGoogleの認証サーバーの両方から参照されることを想定しています。
多くの人が混乱するのは、この認証情報が、互換性のない他の2つの概念と並んで存在している点です。
クライアントID OAuthでアプリを識別します。
API キー ユーザーの委任された認可を伴わない、特定の API 呼び出しにおいてプロジェクトを識別します。
クライアントシークレット シークレットを安全に保持できるフローやアプリタイプでのみ使用される、機密性の高い対になる情報です。
多くの統合エラーは、これらを同じもののバリエーションとして扱ってしまうことから発生します。これらは別物です。
必要な場合 Google でサインイン または ワンタップでは、クライアント ID はフロントエンドが認証ハンドシェイクを開始するために使う値です。Google のドキュメントでは、認証情報を生成する前にアプリを専用の Cloud Console プロジェクトに登録する必要があること、また Web アプリでは完全なスキームとホスト名を含む承認済みの JavaScript オリジンまたはリダイレクト URI を設定する必要があることも説明されています。
ハイブリッドアプリを開発するチームにとって、最も安全な考え方は以下の通りです。
- クライアント ID でアプリを識別する
- 同意画面でユーザーにアプリを提示する
- 適切なアプリタイプを選び、フローにシークレットを含める必要があるかを判断する
アプリの ID と委譲アクセスがどのように組み合わさるかについて、より広範な概要を知りたい場合は、 こちらのアプリ認可ガイド 良い復習になります。Capacitor で OAuth2 をエンドツーエンドで扱う方法は、こちらを参照してください： Capacitor アプリでの OAuth2.
プラットフォーム別のクライアントID設定
Googleログインの設定を失敗させる一番の近道は、一つのクライアントIDですべてのプラットフォームをカバーできると思い込むことです。実際にはできません。マルチプラットフォームアプリでは、各プラットフォームがそれぞれ固有のOAuth 2.0クライアントIDを登録する必要があります。特にAndroidの設定では、所有権を確認するためにSHA1フィンガープリントが必要で、詳細は Google の Android クライアント向け手順.
に記載されています。ユーザーにとっては一つのアプリでも、Googleにとっては複数のOAuthクライアントです。
ある ウェブアプリ、つまり Android ビルド、つまり iOS ビルド、および デスクトップアプリ 同じセキュリティ特性を持っているわけではありません。Google は各プラットフォームに独自のアプリ登録モデルを用意することで対応しています。
実際の使い分けは次のとおりです：
- Web Web クライアント ID を使用し、Origin と Redirect URI を厳格に照合します。
- Androidでは パッケージ ID と SHA1 フィンガープリントに紐付けられた Android クライアント ID を使用します。
- iOSと アプリのbundle identityに紐付けられたiOSクライアントIDを使用します。
- デスクトップまたはElectron シークレットを使用するブラウザフローではなく、インストール型やデスクトップ型のOAuthパターンがよく使われます。
Google Client IDのタイプ比較
| アプリケーションタイプ | 主要な識別子 | Client Secretの提供有無 | 主なユースケース |
|---|---|---|---|
| Web | 承認済みのJavaScriptオリジンおよびリダイレクトURI | 通常は「はい」 | ブラウザアプリとバックエンド支援のWeb OAuth |
| Androidでは | パッケージIDとSHA1フィンガープリント | 多くの場合なし | Androidネイティブサインイン |
| iOSと | アプリバンドルID | 多くの場合なし | iPhone / iPadのネイティブサインイン |
| デスクトップ | インストール済みアプリのID | 多くの場合なし | Electron 風のネイティブフローを含むデスクトップアプリ |
モバイルとデスクトップにおけるクライアントシークレットの矛盾
モバイルおよびデスクトップ開発者は、すべての OAuth クライアントに両方が含まれていることを期待しがちです クライアント ID と クライアントシークレット。その後、彼らは Web アプリケーション の認証情報を作成します。コンソールでシークレットを確認できるのはこの方法だけだからです。
Google の OAuth クライアントに関するガイダンスによると、Android、iOS、インストール済みアプリなどの非 Web アプリケーションタイプでは、クライアント ID は発行されてもクライアントシークレットは意図的に発行されないことがよくあります。これは、ユーザーが抽出できるクライアントサイドソフトウェアに機密のシークレットを埋め込むことを Google が望まないためです。
Capacitor のチームでは、通常、次の2つのアンチパターンのどちらかとして現れます：
- アプリがブラウザベースのフローを開始し、使用するのは Webクライアント で、その後、機密サーバーのように振る舞おうとするパターン。
- アプリが次を送信するパターン： クライアントシークレット バンドルされた code から取得されるため、シークレットを持つ意味がなくなります。
より良いアプローチは、モバイルおよびデスクトップアプリを パブリッククライアント. バックエンドが関与する場合は、機密性の高い操作はバックエンドで行い、ネイティブアプリはパブリッククライアントがすべき範囲に限定してください。
Firebaseを使用するAndroidのサインインにおいて、もう一つ注意すべき点があります。その構成では、 WebアプリケーションタイプのクライアントID がバックエンドサーバーのOAuthクライアントIDとして使用される一方で、Androidアプリは独自のプラットフォーム固有のアイデンティティを保持します。これらは異なる役割を担います。
もしルールを一つだけ覚えるなら、これです： 欲しい認証情報の形式ではなく、code が実行される場所に合わせたクライアントタイプを選択してください.
Google API 認証情報の保護
OAuthに関するインシデントの多くは、複雑な攻撃によるものではありません。チームが認証情報を漏洩させたり、リダイレクト設定を広げすぎたり、本来安全でない場所にシークレットを置いたりすることが原因です。
GoogleのOAuthガイドラインでは、 クライアントシークレット を、自身で管理するサーバー上に置くべき機密性の高い認証情報として扱っています。 クライアント ID は公開識別子ですが、慎重に登録する必要があります。Web アプリの場合、Google は事前登録されたリダイレクト URI とクライアント ID を照合します。リダイレクト URI が厳密に一致しない場合、Google はリクエストを拒否します。
最低限、これだけは正しく行うべき項目：
- アプリの code にクライアントシークレットを絶対に含めないでください。 Web bundle、モバイルバイナリ、Electronパッケージは、ユーザーによる解析が可能です。
- リダイレクトURIは正確に登録する。 「だいたい合っている」では不十分です。GoogleのWebフローでは厳密な一致が検証されます。
- オリジンを厳格に管理する。 セットアップの手間を省くために、広範なドメインを許可しないでください。
- プラットフォームごとに認証情報を分ける。 利便性のために、Android、iOS、Webを一つの認証情報にまとめないでください。
トラブルを回避しているチームは、OAuth 認証情報を他の本番環境シークレットと同様に扱います。Web クライアントシークレットはバックエンドに保持し、環境変数管理で注入し、コンソールへのアクセス権限を監査します。リリースパイプラインの整理を進めている場合、このガイドでは CI/CDパイプラインにおけるシークレット管理 は、認証設定にも応用する価値があります。
よくあるクライアントIDエラーのトラブルシューティング
Google OAuthの失敗の多くは、少数の設定ミスが原因です。エラーメッセージは必ずしも分かりやすくありませんが、どこを見ればよいか分かれば、根本的な問題はたいてい単純です。
redirect_uri_mismatch
アプリが、その Web クライアントに登録されているものと完全に一致しないリダイレクト URI を送信しています。スキーム、ホスト、パス、および末尾の差異を確認してください。
invalid_client
通常、これはアプリが誤ったクライアント ID を送信している、そのクライアント用の誤ったシークレットを使用している、またはプラットフォーム間で認証情報を混同していることを意味します。
origin_mismatch （JavaScript フロー）
ページオリジンが以下にリストされていません 承認済みの JavaScript 生成元 Webクライアント用。
Googleサインインが有効な場合、少なくとも1つのクライアントIDが必要です（Supabase、Firebase、同様のダッシュボードなど）
プロバイダーのトグルがオンですが、 WebクライアントID フィールドが空か、誤ったプロジェクトから貼り付けられています。Google Cloud ConsoleでOAuthクライアントを作成してください。Supabaseの場合、対応プラットフォームをリリースする際は、Web、Android、iOSのクライアントIDをカンマ区切りで入力し、WebクライアントIDを先頭に配置してください。ネイティブクライアントを設定してから保存します。SupabaseとCapacitorを併用する場合は、 SupabaseでのCapacitorソーシャルログイン設定.
DEVELOPER_ERROR、エラー10、またはAndroidでデバッグ時はサインイン成功だが本番環境で失敗する
Android OAuthクライアントが欠落しているか、 パッケージ名 / SHA-1 ペアが、ユーザーが実行するAPKに署名したキーストアと一致しません。ストアビルドにはPlay App Signing証明書のフィンガープリントを追加してください。プラグインが以下を使用していることを確認してください。 WebクライアントID で、SDK はサーバークライアントIDを期待します。 Capgo Social Login ドキュメント.
Google Sign-InはWebでは動作するがモバイルでは失敗する
まずクライアントタイプを確認してください。ネイティブフローでは、WebクレデンシャルはAndroidやiOSクライアントの代わりにはなりません。
同意画面の表示が正しくない
Google Cloud ConsoleのOAuth同意画面で、アプリケーション名とブランディングを確認してください。
実践的なデバッグの順序はシンプルです： まずクライアントタイプ、次にリダイレクト設定、プラットフォーム識別子、そしてそもそもそのシークレットがフローに含まれるべきかどうかの順に確認します.
よくある質問
WebクライアントIDとAndroidクライアントIDは、同じGoogle Cloudプロジェクトに含める必要がありますか？
はい。AndroidのGoogle Sign-Inでは、Androidクライアント（パッケージ名とSHA-1）とWebアプリケーションクライアントを同じGoogle Cloudプロジェクトに作成します。アプリはWebクライアントIDをサーバークライアントIDとして渡し、GoogleはAndroidクライアントが同じプロジェクトに属していることを確認します。不一致はDEVELOPER_ERRORのよくある原因です。 Capgo ソーシャルログインプラグイン ドキュメントにセットアップ手順が記載されています。
Google クライアント ID とは何ですか？
アプリの認証情報を作成する際に Google から割り当てられる、OAuth 2.0 の公開識別子です。通常、以下のような形式をしています： 123456789012-abcdefg.apps.googleusercontent.comGoogle は、アプリが Sign in with Google を開始するときや、認可コードをトークンに交換するときにこれを使用します。
Google クライアント ID はどこで確認できますか？
Google Cloud Console で、次を開きます： Google Auth Platform > クライアント または APIとサービス > 認証情報、次に OAuth 2.0 クライアントを開きます。その クライアントID フィールドに、コピーする文字列全体が表示されます。
Android と iOS のクライアントには、クライアントシークレットが含まれますか？
通常は含まれません。インストール型アプリはパブリックな OAuth クライアントです。クライアントシークレットは、自分で管理するサーバー上でのみ、通常は併用する形で使用してください。 Web アプリケーション OAuthクライアント。
バックエンドが「少なくとも1つのクライアントIDが必要です」と表示するのはなぜですか？
ダッシュボードでGoogleサインインは有効化されていますが、クライアントIDが保存されていません。Google Cloud ConsoleでOAuthクライアントを作成し、ユーザーに機能を有効化する前に、少なくともWebクライアントIDをプロバイダー設定に貼り付けてください。
AndroidでDEVELOPER_ERRORを修正するには？
正しいパッケージ名と、デバイス上の署名キーに対応するSHA-1でAndroid OAuthクライアントを登録してください。Google Play経由で配布する場合は、Play App SigningのSHA-1も含めてください。WebクライアントIDは、認証SDKが期待するものと一致させてください。
1つのクライアントIDをすべてのプラットフォームで再利用できますか？
いいえ。Web、Android、iOS用にそれぞれ別のOAuthクライアントを作成してください。Capacitorアプリでは、ユーザーからは1つの製品に見えても、通常は3つすべてを設定します。
チームで Capacitor や Electron アプリをリリースしている場合、認証のバグが単発で終わることは稀です。たいていはリリースのプレッシャー、ロールバックの必要性、環境固有の修正と同時に表面化します。 Capgo ストア審査を待たずにアプリの code やアセットへ狙ったアップデートを配信できるので、本番に混入したログインフローやコールバック処理、クライアント側の認証問題の修正がはるかに楽になります。
