Google OAuth

Google Sign-Inのインテグレーションが簡単なはずですが、クレデンシャル画面にたどり着いて、1つのアプリタイプがクライアントシークレットを提供し、もう1つのアプリタイプが提供しない理由を理解できません。Capacitor、Ionic、Electron、または混合Webとネイティブのスタックで開発している場合は、混乱は正常です。

実装を実行する際に、ガイドが省略する部分は、実際の実装を破壊するものです。 Google Client IDsはプラットフォーム固有のもの、および非Webアプリの種類は しばしば クライアントシークレットを取得することは設計上できない

間違った資格情報を作成して、フローにシークレットを強制することは、通常、OAuth設定が壊れてデバッグが困難になる

目次
Googleエコシステムにアプリを接続する
- Google Client IDとは何か
- 単純なメンタルモデル
クライアントIDGoogleの実践における位置付け
プラットフォーム固有のクライアントID設定
Google API資格情報のセキュリティ
- 直ちにロックダウンすべきもの
- セキュアなチームが実際に何をするか
一般的なクライアントIDエラーのトラブルシューティング
- ほとんどの失敗を解決する修正

Googleエコシステムにアプリを接続する

多くのチームが同時にこの問題に直面します。 Googleでサインイン, またはユーザーがドライブやカレンダーなどの何かへのアクセスを承認したい場合、APIキーが突然十分ではなくなります。

ユーザーによるサインインと委任されたアクセスはOAuthを通じて実行されるためです。Googleには、__CAPGO_KEEP_0__が呼び出されているだけではあまりにもあなたのアプリを特定できないため、アプリを識別する方法が必要です。 Google Client IDは、そのような認証を行うために必要なクレデンシャルです。, not just the API being called. The credential that does that is the 実用的なOAuth設定は、以下の実装に関する質問に回答することで実現されます。.

どのようなアプリケーションタイプを作成するか

クライアントシークレットが必要かどうか

どのリダイレクトURIまたはオリジンが厳密に一致する必要があるか
モバイルとウェブフローのワイヤリングは、クレデンシャルを混ぜないようにするにはどのように実行するか
Sign in with Google
or they want user-approved access to something like Drive or Calendar, and an __CAPGO_KEEP_0__ key suddenly stops being enough.
ブラウザで動作するフローがネイティブラッパー内で失敗する理由

実用的なルール： ユーザーの許可またはサインインを要求するアプリは、OAuthクライアントのタイプを考慮し始めてください。API キーではなく。

この区別は早期に時間を節約し、ネイティブモバイルログインフローを構築する際に、コンソールが表示するフィールドが多いWeb認証情報に頼る一般的なミスを防ぎます。Capacitor アプリで実装している場合、このガイド Capacitor アプリでのOAuth2 はアプリ側のフローと共に便利な相談相手です。

Google Client IDとは何か

A Google OAuth 2.0クライアントID はGoogleの認証システムにおけるアプリケーションのパブリック識別子です。Googleは、Google認証エンドポイントからアクセストークンを要求する際のアプリケーションのユニークユーザー名として説明し、API キーと区別し、トークン交換中のアプリのアイデンティティを検証するセキュリティ層として機能することを強調しています。詳細は Google CloudのOAuthクライアントドキュメント.

で説明されています。

単純な認識モデル

アプリの認識モデルを考えてみてください クライアントID Google __CAPGO_KEEP_0__ の問題は、アプリの パブリックユーザー名.

Google に「このリクエストは、この登録済みアプリケーションから来ています」と伝えます。

サインイン、同意、トークン交換、ユーザーの代わりにアプリが行動を求めるすべてのフローで、このクライアント ID は重要です。

クライアント ID は、両方のアプリと Google の認証サーバーが参照できるように設計されています。 このクレデンシャルが混乱を招くのは、2 つの概念が入れ替えられないことです。
API key identifies a project for certain API calls that don’t involve delegated user authorization.
__CAPGO_KEEP_0__ キー __CAPGO_KEEP_0__は、秘密を安全に保持できるフローとアプリタイプのみで使用される機密情報の対称値です。

多くの不完全な統合は、誰かがこれらを同じものとして扱うときに始まります。そうではないのです。

クライアントIDGoogleの実際の位置

必要な場合は Googleでサインイン または One Tap、クライアントIDは、認証ハンドシェイクを開始するためにフロントエンドで使用される値です。Googleのドキュメントでは、クレデンシャルを生成する前にアプリを専用のCloud Consoleプロジェクトに登録する必要があることも、Webアプリには、フルスキームとホスト名を含む有効化された認可されたJavaScriptオリジンまたはリダイレクトURIが必要であることも記載されています。

そのため、シンプルなキーを生成するのと比べてセットアップが厳密な感じがするのは、Googleが単にアクセスを許可するのではなく、認証要求を知られているアプリのアイデンティティと結びつけるからです。

ハイブリッドアプリを構築するチームにとって、安全なメンタルモデルは次のとおりです。

クライアントIDをアプリを識別するために使用する
同意画面をユーザーにアプリを表現するために使用する
正しいアプリの種類を使用して、シークレットがフローに属するかどうかを判断する

アプリのアイデンティティと委任されたアクセスがどのように関係しているかについてのより広範な概要を知りたい場合はアプリの認可のガイドこのガイドは、再度確認するのに役立ちます。

クライアントIDを作成して表示する方法

コンソールパスは変更されたため、開発者はよく間違っています。彼らはほとんどの場合、間違っていません。Googleは現在、次の2つのナビゲーションルートを公開しています:新しい Google Auth Platform > Clients パスと古い APIs & Services > Credentials パスについては、 Googleのセットアップドキュメント.

Google CloudコンソールでOAuth 2.0クライアントクレデンシャルを作成している人を表す人がタイプするパソコンのスクリーンショット

コンソールエリアで始めましょう

Google Cloud Consoleを開き、認証設定を所有するプロジェクトを選択または作成してください。認証をランダムなプロジェクトに散らすと、後でアウディットやサポートが苦痛になるので、避けてください。

そこから、次のいずれかの場所へ進みます。

Google Auth Platform > Clients
APIs & Services > Credentials

If your team sees different navigation labels, that’s expected. Google has been separating identity setup from the rest of the API credential surface.

認証情報を作成する際は、自分を制限しないように

OAuthクライアントを作成する際の最大の決定は、 アプリケーションタイプです。Googleは、特定のタイプを選択するように求めています。たとえば、 Web, Android, iOS, or Desktop. その選択は外観的なものではなく、どのアプリが識別され、どのようなサポート設定が必要になるかを定義します。

ウェブアプリの場合、次の値を入力することを予想してください:

認可されたJavaScriptのオリジン
認可されたリダイレクトURI

その値は厳密に一致する必要があります。ウェブクレデンシャルでは、Googleはフルスキームとホスト名、例えば https://www.example.comを期待します。

ドメインの概念を緩いものとしてではなく、 this Capacitor social login setup with Supabase Capgoの__CAPGO_KEEP_0__のソーシャルログイン設定とSupabaseの例は、これらの要素がどのように組み合わさるかを示す便利な例です。

このウォークスルーは、クリックしてUIを比較したい場合は、視覚的な参照として十分なものです。

後でどこで見つけるか

クライアントIDはプロジェクトのクレデンシャルリストに表示されます。同様のプロジェクトスペースでは、チームはAPIを有効化し、OAuth IDの連携をconsent画面で確認することもできます。登録されたアプリケーション名は、許可のプロンプトでユーザーが見るものであり、これがアプリケーション名を正確に設定する理由の1つです。

Googleはこれらのクレデンシャルを管理するために時間を費やします。クライアントIDをコピーする、設定を確認する、適用可能な場合にはクライアントシークレットを管理するなど、ダッシュボードに戻ってください。

consent画面は装飾ではありません。信頼境界の一部です。ユーザーはアプリケーション名をそこで見ますが、内部プロジェクトのニックネームではありません。

プラットフォーム固有のクライアントID構成

Googleログイン設定を破る最速の方法は、1つのクライアントIDがすべてのプラットフォームをカバーできるものと想定することです。そうはいけません。マルチプラットフォームアプリの場合、各プラットフォームは独自のOAuth 2.0クライアントIDを登録し、AndroidのセットアップにはSHA1の指紋を所有権を検証するために必要なので、このプラットフォーム設定の参考.

1つのアプリが複数のクライアントIDを必要とする理由

ユーザーにとっては1つのアプリですが、Googleにとっては複数のOAuthクライアントです。

A ウェブアプリ、 Androidビルド、 iOSビルド、 デスクトップアプリ 同じセキュリティ特性を提示しない。同様に、同一の方法でアイデンティティを証明せず、すべてのプラットフォームが信頼できる環境でクレデンシャルを保存していない。

Googleはそれを解決するために、各プラットフォームに独自のアプリ登録モデルを提供しています。

その分離は、良いセキュリティの衛生です。1つのプラットフォームのクレデンシャル設定が侵害または不正設定された場合、他のプラットフォームは自動的に露呈されません。

実際の分離の方法は次のとおりです。 Web
WebクライアントIDと厳格なオリジンとリダイレクトURIのマッチングを使用します。 AndroidクライアントIDはパッケージのアイデンティティとSHA1の指紋に紐付けられます。
iOS iOSクライアントIDはアプリのバンドルアイデンティティに紐付けられます。
Desktop or Electron デスクトップまたはElectronでは、秘密を使用したブラウザーフローではなく、インストールされたまたはデスクトップスタイルのOAuthパターンがよく使用されます。

Google Client IDのタイプの比較

アプリケーションタイプ	主な識別子	クライアントシークレットを提供する?	主な使用ケース
Web	認可されたJavaScriptのオリジンとリダイレクトURI	通常はいえます	ブラウザアプリとバックエンドアシストウェブOAuth
Android	__CAPGO_KEEP_0__ + SHA1の指紋	しばしばはいえません	ネイティブAndroidのサインイン
iOS	アプリバンドル識別子	しばしばはいえません	ネイティブiPhoneとiPadのサインイン
デスクトップ	インストール済みアプリの識別子	よくないことは	デスクトップアプリ、Electronスタイルのネイティブフローを含む

モバイルとデスクトップ向けのクライアントシークレットのジレンマ

多くのチュートリアルでは、この部分が間違っている。

モバイルとデスクトップ向けの開発者は、OAuthクライアントに両方の クライアントID と クライアントシークレットが含まれることを期待する。すると、コンソールでシークレットを表示できるように、Webアプリケーション用のクレデンシャルを作成する。フローは完成したように見えるので、開発者は進めていく。しかし、後で認証が混乱したように失敗する。 Capgoによると __CAPGO_KEEP_0__.

__CAPGO_KEEP_0__. モバイル認証の不一致の説明非Webアプリケーションの種類、例えばAndroid、iOS、インストール済みアプリは、クライアントIDを受け取るが、意図的にクライアントシークレットを受け取らない。Googleは、ユーザーがクライアント側ソフトウェアから抽出できる秘密のシークレットを含めることを避きたいからだ。

その設計は正しい。モバイルアプリまたはElectronバンドルは、秘密のシークレットを安全に保存する場所ではない。

これが機能する: パブリッククライアント向けに設計されたネイティブまたはクライアントサイドのOAuthフロー。
これが機能しない: モバイルアプリ用にWeb認証を作成して、実装にシークレットを強制すること。

For Capacitor チームにとって、これは通常、2 つの悪いパターンのいずれかで表れる:

アプリはブラウザベースのフローを実行し、"web client"と呼ばれるクライアントを使用し、次に秘密のサーバーと同じように振る舞う。 アプリは web client
を使用して client secret codeから埋め込まれたものは、秘密を隠すことの意味を無くす。

モバイルとデスクトップアプリを public clientsとして扱う方がいい。現代のOAuthでは、秘密がクライアント内に隠されていることを依存しないフローを使うことが多い。バックエンドが絡む場合は、秘密を含む操作はバックエンドで行い、ネイティブアプリはpublic clientとしての役割に限定する。

Firebase-backed Android sign-inの場合、もう一つの重要な点がある。 web application type client ID はバックエンドサーバーのOAuthクライアントIDとして使われ、Androidアプリは独自のプラットフォーム固有のIDを持つ。両方のクレデンシャルが同じプロジェクト内で見え、1つが他を置き換えるものと誤解されることがあるが、実際はそうではない。

1つのルールを覚えておけばいい。 codeが実行される場所のクライアントタイプを選ぶのではなく、望ましいクレデンシャル形状を選ばないでください.

Google APIのセキュリティ設定

OAuthのインシデントの多くは複雑な攻撃ではなく、チームがクレデンシャルを漏洩させたり、リダイレクト設定を広く設定したり、秘密を安全でない場所に置いたりすることによるものだ。

GoogleのOAuthガイドラインでは、クライアントIDとシークレットをプライベートデータとして扱うことを強調しています。ウェブアプリケーションでは、クライアントIDは事前登録されたリダイレクトURIに対して強制されています。リダイレクトURIが厳密に一致しない場合、Googleはリクエストを拒否します。このオリジンバインディングは、OAuth.comのクライアント登録ガイドラインで説明されているトークンインテリセプションの保護の一部です。プロフェッショナルな開発者がオフィスでセキュリティクレデンシャルを確認するためにデュアルモニターのコンピューターを使用しています。.

すぐにロックダウンするべきもの

あなたが何をしても、次のことを正しく行うだけでも十分です。

アプリケーションにクライアントシークレットを送信しないでください。

Never ship a client secret in app code. 正確なリダイレクトURIを登録してください。
十分ではありません。ウェブフローではGoogleが厳密な一致を検証します。 オリジンをきつく抑えてください。
広いドメインを認可しないでください。セットアップの摩擦を回避するために。 プラットフォームクレデンシャルを分離してください。
__CAPGO_KEEP_0__ Android、iOS、ウェブを1つの資格情報に押し付けるのを許さない。

1 つの運用上の詳細は、簡単に見過ごされる。Google は、既存のクライアント ID に新しいシークレットを生成し、古いものを無効化することをチームに許可している。そうすることは、シークレットが漏洩した場合や、デプロイメントプロセスを強化している場合に重要である。

実際に安全なチームが行うこと

トラブルを避けるチームは、OAuth 資格情報を他の生産シークレットと同様に扱う。

ウェブクライアントシークレットはバックエンドで保管し、環境管理を通じてインジェクトし、コンソールへのアクセスを監査する。リリースパイプラインを整理している場合、このCI/CD パイプラインでのシークレットの管理に関するガイドは、認証設定にも適用する価値がある。また、メタデータをレビューすることも行う。OAuth の同意画面は、ユーザーが見るクライアント ID とつながっている。アプリケーション名が曖昧または誤解を招く場合は、ユーザーは提示された画面を信頼しない可能性が高く、誤ったアプリケーションに承認する可能性もある。

セキュリティは、シークレットを隠すことだけではなく、正しいアプリケーション ID、リダイレクトターゲット、および承認画面が毎回一致するようにすることにもある。

一般的なクライアント ID エラーのトラブルシューティング

ほとんどの Google OAuth の失敗は、設定ミスによるものである。エラーテキストは親切ではないかもしれないが、問題の根本原因は、どこに注目すればよいかわかれば、簡単に解決できる。

ほとんどの失敗を解決するための修正

redirect_uri_mismatch

アプリが登録されているウェブクライアントの URI に一致しないリダイレクト URI を送信しているようです。Scheme、ホスト、パス、末尾の差異を確認してください。ウェブ OAuth の場合、厳密な一致はセキュリティモデルの一部です。

invalid_client

これは、通常、クライアント ID が間違っている、またはそのクライアントのシークレットが間違っている、またはプラットフォームをまたがってクレデンシャルを混在させていることを意味します。Android または iOS フローが間違ってウェブクレデンシャルを使用している例がよくあります。

invalid_request

このエラーは広範囲にわたりますが、クロスプラットフォームアプリでは、よくマルチフォーマットの認証パラメータが不正確である、またはクライアントのタイプに合わないフローが実行されていることを示しています。アプリがシークレットを含めるべきところで含めていないか、選択した OAuth フローが異なる種類のクライアントを想定しているかどうかを確認してください。

Google Sign-In はウェブで動作しますが、モバイルでは失敗します。

最初に調べるべきことはクライアントのタイプです。モバイル開発者にとって最も一般的なエラーの原因は、ウェブアプリケーションクライアント ID を作成してクライアントシークレットを取得したいだけだからです。しかし、Android または iOS のタイプを使用する必要があります。これらのタイプは、説明されているように、意図的にシークレットを省略することがよくあります。クライアントシークレットの不一致についてのこの解説を参照してください。トークンライフサイクル作業を含む実装があります。サインイン後にトークンを削除する場合、この削除ガイドは役立ちます。

Android のサインインが認証情報の作成後に失敗します。

Android クライアントに紐付けされた SHA1 フィンガープリントをもう一度確認してください。署名の ID が Google の期待どおりになっていない場合、アプリが所有権を正しく証明できないため、サインインが失敗します。

Consent スクリーンが不正確です

OAuth設定のコンソールで確認するアプリ名とブランドを検証してください。ユーザーはそこで見たものを承認するので、不正なメタデータは信頼性の問題とサポートのノイズを生じます。

実用的なデバッグの順序は簡単です: クライアントタイプを確認し、次にリダイレクト設定、次にプラットフォーム識別子、最後にシークレットがフローに含まれるべきかどうかを確認します.

Capgoを使用してアプリをCapacitorまたはElectronアプリを開発するチームは、authのバグがほとんどが孤立してしまわないことが多いです。通常、リリースのプレッシャー、ロールバックの必要性、環境固有の修正とともに表面化します。 Capgo code

GoogleクライアントIDを取得する：2026年のガイド