You’re probably here because Google Sign-In should have been a quick integration, and instead you’re staring at a credentials screen wondering why one app type gives you a client secret and another doesn’t. That confusion is normal, especially if you’re building with Capacitor, Ionic, Electron, or a mixed web and native stack.
実装を実際に動くものにするのは、ほとんどのガイドが省略している部分です。 Google Client IDs はプラットフォームごとに異なります。実装が破綻するのは、ほとんどのガイドが省略している部分です: don’t , そしてウェブアプリ以外のタイプは通常、クライアントシークレットを取得する設計ではありません。 ただし、クライアントシークレットを強制的に流れに挿入するために、間違ったクレデンシャルを作成すると、通常、OAuth設定が壊れて、デバッグが困難になります。
目次
- Google エコシステムにアプリを接続する
- Google クライアント ID とは
- クライアント ID を作成して表示する方法
- プラットフォーム固有のクライアント ID 設定
- Google API のセキュリティ
- クライアントIDのエラーを解決する
Google エコシステムにアプリを接続する
多くのチームは同時にこの問題に直面します。彼らは Google でのサインイン、またはドライブやカレンダーなどのユーザーが承認したアクセスを得たい場合、API キーが突然不足になることがあります。
ユーザーがサインインし、委任されたアクセスを実行するのはOAuth経由で行われるためです。Googleは アプリを識別する方法が必要です、単に API が呼び出されていることだけではありません。 Google Client ID.
複数のプラットフォームで作業している場合、混乱はすぐに悪化します。Web フロントエンド、Android シェル、iOS アプリ、デスクトップ用の Electron ビルドなど、共通の OAuth ID を共有することは避けるべきです。
実用的な OAuth 設定は、実装上のいくつかの質問に帰着します。
- どのアプリケーションタイプを作成するか
- クライアントシークレットが必要かどうか
- どのリダイレクト URI またはオリジンが厳密に一致する必要があるか
- モバイルと Web フローのワイヤリングを実行する際に、クレデンシャルを混ぜないようにする
- ブラウザ内で機能するフローがネイティブラッパー内で機能しない理由
実用的なルール: アプリがユーザーの許可またはサインインを要求している場合、OAuth クライアントタイプを考慮し始めてください。 API キーではありません。
この区別は、早期に時間を節約します。ネイティブ ラッパー上で Web クレデンシャルを使用してログインフローを構築することの一般的な間違いを防ぎます。ただし、コンソールがより多くのフィールドを表示したためです。 Capacitor アプリケーションを実装している場合、このガイドを参照してください OAuth2 in Capacitor アプリ __CAPGO_KEEP_0__ アプリでは便利なオーサー フロー用のパートナー
Google Client ID とは
A Google OAuth 2.0 クライアント ID is the public identifier for your application in Google’s auth system. Google describes it as the unique username for an application when requesting access tokens from Google authentication endpoints, and notes that it’s distinct from API keys because it’s used in OAuth flows to verify the app’s identity during token exchange, as explained in Google CloudのOAuthクライアントドキュメント.
Google Cloud の OAuth client ドキュメント
Google Client ID は、アプリケーションのユニークな ID とセキュリティ層として機能します。 単純な認識モデル Google Client ID を発行することは、アプリの パブリックユーザー名.
Googleに「このリクエストは、この登録済みアプリケーションから来ています」と伝えます。そのため、サインイン、同意、トークン交換、ユーザーを代表してアプリが行動を求めるすべてのフローで重要です。クライアントIDは、アプリとGoogleの認証サーバー両方が参照することを意図しています。
この資格情報が混乱を招くのは、2つの概念が入れ替えられないことを認識していないことです。
クライアントID OAuthでアプリを識別します。
APIキー API呼び出しを実行するプロジェクトを識別します。ユーザー認証が必要ない場合に限ります。
クライアントシークレット 安全にシークレットを保持できるフローとアプリタイプで使用される、秘密の対称物です。
多くのインテグレーションが破損するのは、誰かがこれらを同じものとして扱うことです。そうではありません。
クライアントIDのGoogleの実際の位置
もし必要な場合 Googleでサインイン または 1タップクライアントIDは、フロントエンドが認証ハンドシェイクを開始するために使用する値です。Googleのドキュメントでは、クレデンシャルを生成する前にアプリを専用のCloud Consoleプロジェクトに登録する必要があることも指摘しています。また、Webアプリには、フルスキームとホスト名を含む有効化されたJavaScriptオリジンまたはリダイレクトURIが必要です。
Googleはアクセスを有効にするだけではありません。認証要求を知られているアプリのアイデンティティにバインドしています。
ハイブリッドアプリを構築するチームにとって、安全なメンタルモデルは次のとおりです。
- クライアントIDをアプリを識別するために使用する
- 同意画面をユーザーにアプリを表現するために使用する
- 正しいアプリタイプを使用して、シークレットがフローに含まれるかどうかを決定する
アプリのアイデンティティと委任されたアクセスがどのように関係しているかについてのより広範なプライマーを求めている場合は アプリ認証のガイド は、リフレッシュするのに役立ちます。
クライアント ID の作成と表示方法
コンソールのパスが変更されたため、開発者はよく間違っています。実際には、ほとんどの場合、間違っていません。Google は、現在、次の 2 つのナビゲーション ルートを提供しています。 Google Auth Platform > Google クライアント APIs & Services > Credentials Google のセットアップ ドキュメント Google Cloud Console で OAuth 2.0 クライアント認証情報を作成するための画面を表示するパソコンのキーボードを操作する人 正しいコンソールエリアから始めます.
その後、次のいずれかの場所に移動してください。
Open the Google Cloud Console and select or create the project that will own the auth configuration. Don’t scatter auth across random projects. It makes auditing and support painful later.
そのあと、どちらかの場所へ移動してください。
- Google Auth Platform > Google クライアント
- APIs & Services > ID とアクセス許可
Googleは、チームが異なるナビゲーションラベルを確認することを想定しています。Googleは、アイデンティティのセットアップを他のAPI資格情報の表面から分離してきました。
新しいクレデンシャルを作成する際に自分を制限しないように
OAuthクライアントを作成する際に最も大きな決定は アプリケーションの種類. Googleは、Web Android, iOS, , またはDesktop を選択するよう求めます。その選択は外観に限られていません。アプリが識別され、必要なサポート設定が定義されます。
ウェブアプリの場合、次の値を入力する必要があります:
- 有効なJavaScriptのオリジン
- 有効なリダイレクトURI
その値は正確でなければなりません。ウェブ認証情報の場合、Googleはフルスキームとホスト名を想定しており、 https://www.example.com、ではなく、曖昧なドメイン概念
モバイルプラットフォームの場合、形状は異なります。Androidの登録にはパッケージレベルのアイデンティティと所有権の検証が必要ですが、iOSは独自のプラットフォーム識別子を使用します。Google認証を他の認証層と組み合わせる場合、 このCapacitorのソーシャルログイン設定とSupabase は、これらの要素がどのように組み合わさるかを比較するための視覚的な参照として、このウォークスルーを使用できます:
それを後で見つける場所
クライアントIDはプロジェクトのクレデンシャルリストに表示されます。その同じプロジェクトスペースは、チームがAPIを有効化し、OAuth IDがconsent画面に接続されているかどうかを確認する場所でもあります。登録されたアプリケーション名は、許可のプロンプトでユーザーが見るものであり、これがアプリケーション名を正確に設定することの重要性の1つです。
Googleはこれらのクレデンシャルを管理するために、時間の経過とともにクライアントIDをコピーすることができます、設定を確認し、適用される場合、クライアントシークレットに関連付けられたクレデンシャルを管理することもできます。
クライアントIDの表示場所
承認画面は装飾ではありません。信頼の境界の一部です。ユーザーはそこでアプリ名を確認しますが、内部プロジェクトのニックネームではありません。
プラットフォーム固有のクライアントID設定
Googleログイン設定を破る最速の方法は、1つのクライアントIDがすべてのプラットフォームをカバーできるものと仮定することです。できません。マルチプラットフォームアプリの場合、各プラットフォームは独自のOAuth 2.0クライアントIDを登録し、Androidの設定ではSHA1の指紋を所有権を確認するために必要です。 1つのアプリが複数のクライアントIDを持つ理由.
ユーザーにとっては1つのアプリですが、Googleにとっては複数のOAuthクライアントです。
A
ウェブアプリ 、Androidビルド iOSビルドAndroidビルド iOS ビルド、そして デスクトップアプリ セキュリティの性質を同じように提示していない。同様に、同様にアイデンティティを証明していないし、信頼できる環境でクレデンシャルを保存していない。Googleはそれを解決するために、各プラットフォームに独自のアプリ登録モデルを提供している。
その分離は、セキュリティ上の良い衛生です。もし1つのプラットフォームのクレデンシャル設定が侵害されたり、不正に設定されたりしたら、他のプラットフォームは自動的に露呈されません。
実際的な分離は以下のようになっています。
- Web WebクライアントIDを使用し、厳格なオリジンとリダイレクトURIのマッチングを実行します。
- Android AndroidクライアントIDを使用し、パッケージのアイデンティティとSHA1の指紋に紐付けます。
- iOS iOSクライアントIDを使用し、アプリのバンドルアイデンティティに紐付けます。
- デスクトップまたはElectron Google Client ID の種類を比較する
Google Client ID の種類
| アプリケーションタイプ | 主な識別子 | クライアントシークレットを提供するか? | 主な用途 |
|---|---|---|---|
| Web | 認可された JavaScript の起源とリダイレクト URI | 通常はいえます | ブラウザ アプリケーションとバックエンド アシストされた Web OAuth |
| Android | パッケージ ID と SHA1 の指紋 | よくない | ネイティブAndroidのサインイン |
| iOS | アプリパッケージのID | よくない | ネイティブiPhoneとiPadのサインイン |
| デスクトップ | インストール済みアプリのID | よくない | デスクトップアプリ、Electronスタイルのネイティブフロー |
モバイルとデスクトップのクライアントシークレットのジレンマ
この部分は、多くのチュートリアルが間違えている
モバイルとデスクトップの開発者は、OAuthクライアントに両方のクライアントIDとクライアントシークレットが含まれることを期待することが多い。 クライアントID クライアントシークレット シークレットWebアプリケーション Webアプリケーション クレデンシャル
この説明によると、モバイルクレデンシャルミスマッチの説明によると、非WebアプリケーションタイプのAndroid、iOS、インストール済みアプリは、意図的にクライアントシークレットが含まれていないため、クライアントIDのみを受け取ることが多い。 Googleは、ユーザーがクライアント側ソフトウェアからシークレットを抽出するのを防ぐためにそうしている。その設計は正しい。モバイルアプリまたはElectronバンドルは安全なシークレットストアではありません。
これが機能する:
何が機能する: ネイティブまたはクライアントサイドのOAuthフローは、パブリッククライアント向けに設計されています。
何もありません: モバイルアプリ用にウェブ認証情報を作成して、実装にシークレットを強制する必要があるのです。
このようなシナリオは、Capacitor チームにとってよく見られる2つの悪いパターンです。
- アプリはブラウザベースのフローを使用してウェブクライアントを起動し、秘密のサーバーと同じように振る舞うのです。 ウェブクライアント より良いアプローチは、モバイルとデスクトップアプリをパブリッククライアントとして扱うことです
- web client クライアントシークレット Capgoからバンドルされたcodeですが、秘密の意味を失います。
web client client secret. modern OAuthでは、クライアントの秘密がクライアント内に隠されている流れに頼る必要がないことが一般的です。 バックエンドが関与する場合は、秘密を保持する操作をバックエンドに留め、ネイティブアプリはパブリッククライアントが実行できるように制限する必要があります。
Firebase-backed Androidサインインの設定では、もう一つの重要な点があります。 その設定では、 webアプリケーションタイプのクライアントID はバックエンドサーバーのOAuthクライアントIDとして使用され、Androidアプリは独自のプラットフォーム固有のアイデンティティを保持します。 その分割はチームが両方のクレデンシャルを同じプロジェクト内で見るため、混乱が生じます。 しかし、1つは他を置き換えるものではありません。 それらは異なる役割を果たします。
あなたが覚えている1つのルールがある場合、それは次のものです。 クライアントのタイプを選択する際は、codeが実行される場所に合わせてください。 それが、クレデンシャル形状を望んでいたものとは異なります。.
GoogleのAPIクレデンシャルをセキュアにする
OAuthのインシデントの多くは、複雑な攻撃ではなく、チームがクレデンシャルを漏洩させたり、リダイレクト設定を過度に広げたり、秘密を安全でない場所に置いたりしたことによるものです。
GoogleのOAuthガイドラインでは、クライアントIDとシークレットをプライベートデータとして扱うことを強調しています。 また、Webアプリケーションでは、クライアントIDは事前に登録されたリダイレクトURIと厳密に一致することを確認します。 リダイレクトURIが厳密に一致しない場合、Googleはリクエストを拒否します。 そのオリジンバインディングは、OAuth.comのクライアント登録ガイドラインで説明されているように、トークンをインテルセプトする保護の一部です。 OAuth.comのクライアント登録ガイドライン.
すぐにロックダウンするべきものは何ですか
あなたができることの数が限られている場合、以下のことを行うことをお勧めします
- Never ship a client secret in app code. ユーザーがアプリケーションをインスペクトできるのは、Webバンドル、モバイルバイナリ、Electronパッケージのみです。
- 正確なリダイレクトURIを登録してください。 「Close enough」では十分ではありません。GoogleはWebフローの厳密な一致を検証します。
- オリジンを狭くしてください。 セットアップのトラブルシューティングを回避するために、広いドメインを認可しないでください。
- プラットフォームのクレデンシャルを分離してください。 Android、iOS、Webのクレデンシャルを1つのクレデンシャルにしないでください。
1つのオペレーショナル詳細は簡単に見過ごされがちです。Googleは既存のクライアントIDに対して新しいシークレットを生成し、古いシークレットを無効化することを許可しています。それは、シークレットが漏洩した場合や、デプロイメントプロセスを強化する場合に重要です。
セキュアなチームの実際の行動
トラブルを避けるチームは、OAuth資格情報を他のプロダクションシークレットと同様に扱います。
セキュアなチームは、Webクライアントシークレットをバックエンドで保持し、環境管理を通じてインジェクトし、コンソールへのアクセスを誰が持っているかを監査します。リリースパイプラインを整理している場合、このガイド CI/CDパイプラインでシークレットを管理する方法 は、認証設定にも適用する価値があります。
また、メタデータをレビューすることも行います。ただし、キーだけではありません。ユーザーが見るクライアントIDと連携しているOAuthの同意画面は、問題が生じる可能性があります。
セキュリティは、シークレットを隠すことだけではなく、正しいアプリケーションID、リダイレクトターゲット、承認画面が常に一致するようにすることでもあります。
クライアントIDのエラーのトラブルシューティング
Google OAuthの失敗の多くは、小さなセットの設定ミスから来ています。エラーテキストは親切ではありませんが、問題の根本原因は、どこを見ればいいかを知っている場合に簡単にわかります。
多くの失敗を解決する修正
redirect_uri_mismatch
アプリケーションは、登録されているWebクライアントのURIと完全に一致しないリダイレクトURIを送信しています。スキーム、ホスト、パス、末尾の差異を確認してください。Web OAuthの場合、完全な一致はセキュリティモデルの一部です。
invalid_client
これは、通常、クライアントIDが間違っている、またはそのクライアントのシークレットが間違っている、またはプラットフォームをまたいだ資格情報を混在させていることを意味します。AndroidまたはiOSフローが間違った場所でWeb資格情報を使用していることがよくあります。
invalid_request
この一つは広いですが、クロスプラットフォームアプリでは、よく不正な認証パラメータやクライアントタイプに合わないフローに指します。アプリがシークレットを含めるべきところでシークレットを含めているか、選択したOAuthフローがシークレットを期待しているかどうかを確認してください。
Google Sign-InはWebで動作しますが、モバイルでは失敗します
最初に調べるべきことはクライアントタイプです。モバイル開発者にとって最も一般的なエラーの原因は、Webアプリケーション用のクライアントIDを作成してシークレットを取得したいだけだと考えてしまい、実際にはAndroidまたはiOSタイプを使用するべきで、シークレットを意図的に省略することが多いことを説明しているこのクライアントシークレットの不一致の解説を参照してください。 Androidのサインインがクレデンシャル作成後で失敗しますAndroidクライアントに付属しているSHA1のハッシュ値をもう一度確認してください。署名のアイデンティティがGoogleが期待しているものと一致しない場合、所有権を証明することができません。
Consent画面が不正です
コンソールでOAuthの設定でアプリケーション名とブランドを確認してください。ユーザーはそこで表示されるものを許可するので、不正なメタデータは信頼性の問題やサポートのノイズを生じます。
実用的なデバッグの順序は簡単です:まずクライアントタイプを確認し、次にリダイレクト設定、次にプラットフォーム識別子、最後にシークレットがフローに含まれるべきところで含まれているかどうかを確認してください
Google Sign-InはWebで動作しますが、モバイルでは失敗します
Androidのサインインがクレデンシャル作成後で失敗します Consent画面が不正です.
あなたのチームが Capacitor または Electron アプリをリリースする場合、認証のバグはほとんどの場合、リリースの圧力、ロールバックの必要性、環境固有の修正と共に表面化します。 Capgo Capgo は、チームが code とアセットにターゲット化されたアップデートをリリースするのを待つことなく、ストアのレビューに依存しないようにします。これにより、ログインフロー、コールバックハンドリング、クライアントサイド認証問題を修正することが容易になります。
