あなたはここに来ているのは、Google Sign-Inが簡単な統合になっていなければならないのに、クレデンシャル画面を見つめていることだろう。なぜ一つのアプリタイプがクライアントシークレットを与え、もう一方は与えないのか、困惑しているだろう。混乱は正常であり、特にあなたがCapacitor、Ionic、Electron、または混合Webとネイティブスタックで構築している場合に尤もである。
ほとんどのガイドが省略しているのは、実際の実装を破壊することである。 GoogleクライアントIDはプラットフォーム固有である、そして非Webアプリタイプは 通常 クライアントシークレットを取得しない
設計によってである。クレデンシャルを間違って作成して、シークレットをフローに強制するだけでは、通常、壊れたOAuth設定に終わる。デバッグは必要以上に難しくなる。
- 目次
- アプリをGoogleエコシステムに接続する
- クライアント ID の作成と表示方法
- プラットフォーム固有のクライアント ID 設定
- Google API のクレデンシャルをセキュアにする
- 一般的なクライアント ID エラーのトラブルシューティング
Google エコシステムにアプリを接続する
多くのチームは同時にこの問題に直面します。彼らは Google でのサインイン, またはユーザーがドライブやカレンダーなどのアクセスを許可したい場合、API キーだけでは突然足りなくなることがあります。
, またはユーザーがドライブやカレンダーなどの何かへのアクセスを承認したい場合、__CAPGO_KEEP_0__ キーが突然十分ではなくなります。 あなたのアプリAPI を呼び出すだけではありません。実行するのは、その API を呼び出すための資格情報です。 , ではなく__CAPGO_KEEP_0__が呼び出されているだけではありません。Googleがアプリを識別するための.
Google Client ID
OAuth実装の基本的な質問に答えることで、実用的なOAuth設定を実現できます。
- 実用的なOAuth設定は、実装上のいくつかの質問に来ることが多いです:
- Google OAuth 2.0 client ID
- Google OAuth 2.0 client ID
- Google OAuth 2.0 client ID
- Google OAuth 2.0 client ID
Google OAuth 2.0 client ID OAuthクライアントタイプで考えるのではなく、API キーで考えるのではなく、ユーザーの許可またはサインインを求めるアプリの場合、OAuthクライアントのタイプから始めてください。
That distinction saves time early. It also prevents the common mistake of building a mobile login flow around a web credential just because the console showed more fields. If you’re implementing this in a Capacitor app, this guide on OAuth2 in Capacitor アプリ Google OAuth 2.0 client ID
Google OAuth 2.0 client ID
A Google OAuth 2.0 クライアント ID Google Client IDは、Googleの認証システムにおけるアプリケーションの公開識別子です。Googleは、Google認証エンドポイントからアクセストークンを要求する際のアプリケーションのユニークなユーザー名として説明し、APIキーと区別して、OAuthフローでアプリのアイデンティティを検証するために使用されることを強調しています。 Google CloudのOAuthクライアントドキュメントを参照してください。.
シンプルな認識モデル
Google Client IDを考えてみましょう。 Google Client IDは、Googleに「このリクエストは、この登録済みアプリケーションから来ています」と伝えるアプリの公開ユーザー名です。 サインイン、同意、トークン交換、ユーザーに対してアプリが代わりに行動する必要があるすべてのフローで、このクライアントIDは重要です。 クライアントIDは、アプリとGoogleの認証サーバー両方によって参照されることを意図しています。.
このクレデンシャルが混乱を招くのは、2つの概念が入れ替えられないことです。
クライアントIDはOAuthでアプリを識別します。
クライアントID クライアントIDはOAuthでアプリを識別します。
APIキー APIキーは、特定のAPIコールがユーザー認証を委任せずに実行される場合に、プロジェクトを識別します。
クライアントシークレット クライアントシークレットは、秘密情報を安全に保つことができるフローとアプリタイプのみで使用される、秘密の対象です。
多くの不完全な統合は、誰かがこれらを同じものとして扱うことから始まりますが、実際にはそうではありません。
クライアントIDGoogleの実際の位置付け
もし Googleでサインイン または One Tapそのため、設定は単純なキーを生成するよりも厳格な感じがします。Googleは単にアクセスを許可するのではなく、認証要求を知られているアプリのアイデンティティと結び付けます。
アプリフロー
ハイブリッドアプリを開発するチームにとって、最も安全なメンタルモデルは次のようになります。
- クライアントIDを使用してアプリを識別する
- ユーザーにアプリを表現するためにconsent画面を使用する
- シークレットがフローに含まれるかどうかを決定するために正しいアプリタイプを使用する
アプリのアイデンティティと委任されたアクセスがどのように関係しているかについてより広範なプライマーを求めている場合は、 アプリの認可ガイド クライアントIDを作成して表示する方法
クライアントIDの作成と表示方法
Google Auth Platform > Clients パスと古い APIs & Services > Credentials APIs & Services > ID情報 パス、Googleのセットアップドキュメントに記載されているように Googleのセットアップドキュメント.
適切なコンソールエリアから始めましょう
Google Cloudコンソールを開き、認証設定を所有するプロジェクトを選択または作成します。認証をランダムなプロジェクトに散らすのは、後でアウディティングやサポートが苦痛になるからです。
ここから、次のいずれかの場所へ進みましょう
- Google Auth Platform > クライアント
- APIs & Services > 資格情報
Googleは、チームが異なるナビゲーションラベルを確認することを予想しています。Googleは、アイデンティティの設定を他のAPI資格情報の表面から分離してきました。
資格情報を作成する際に自分を閉じ込めるのを避けましょう
OAuthクライアントを作成する際の最大の決定は、 アプリケーションタイプ. Google は、特定のタイプを選択するように求めています Web, Android, iOS, または Desktop. その選択は外観に限りません。アプリが識別され、必要なサポート設定が定義されます。
Web アプリの場合、次の値を入力することを期待します。
- 認可されたJavaScriptオリジン
- 認可されたリダイレクト URI
その値は正確でなければなりません。Web 認証では、完全なスキームとホスト名、例えば https://www.example.com, ではなく、汚いドメインの概念ではありません。
モバイルプラットフォームでは形状が異なります。Androidの登録にはパッケージレベルのIDと所有権の検証が必要ですが、iOSは独自のプラットフォームIDを使用します。Google認証を他の認証層と組み合わせる場合 Capacitor は、Supabaseと組み合わせたこの社会ログイン設定
は、これらの要素がどのように組み合わさるかを示す便利な例です。
このウォークスルーは、UIを比較するためにクリックして進む際に視覚的な参照として十分です。
ここで見つけることができます。
クライアント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 Webアプリ, Androidビルド, iOSビルド, デスクトップアプリ セキュリティ上の性質を同じに提示していません。同様に、同様にアイデンティティを証明できず、信頼できる環境でクレデンシャルを保存していません。Googleはそれぞれのプラットフォームに独自のアプリ登録モデルを提供します。
その分離は、セキュリティ上の良好な衛生です。1つのプラットフォームのクレデンシャル設定が侵害または不正設定された場合、他のプラットフォームは自動的に露呈されません。
以下の実用的な分割を実行してください:
- Web WebはWebクライアントIDと厳格なオリジンとリダイレクトURIのマッチングを使用します。
- Android AndroidはパッケージのアイデンティティとSHA1の指紋に紐付けられたAndroidクライアントIDを使用します。
- iOS iOSはアプリのバンドルIDに紐付けられたiOSクライアントIDを使用します。
- デスクトップまたはElectron Desktop or ElectronはインストールされたまたはデスクトップスタイルのOAuthパターンを使用することが多く、シークレットを使用したブラウザーフローではありません。
Google Client IDの比較
| アプリケーションタイプ | 主な識別子 | クライアントシークレットを提供しますか? | 主な使用例 |
|---|---|---|---|
| Web | 有効化されたJavaScriptの起源とリダイレクトURI | 通常はいえ | ブラウザアプリとWeb OAuthのバックエンドアシスト |
| Android | パッケージのIDとSHA1の指紋 | しばしばいいえ | ネイティブのAndroidのサインイン |
| iOS | アプリケーションバンドルのID | よくない | ネイティブiPhoneとiPadのサインイン |
| デスクトップ | インストール済みアプリのID | よくない | Electronスタイルのネイティブフローを含むデスクトップアプリ |
モバイルとデスクトップ向けのクライアントシークレットのジレンマ
これは、多くのチュートリアルが間違っている部分です。
モバイルとデスクトップ向けの開発者は、OAuthクライアントに両方の クライアントID と クライアントシークレットでは、クライアントIDを取得します。 Webアプリケーション クレデンシャルを作成する必要があります。そうでないと、コンソールでシークレットを表示することはできません。
フローは完成したように見えます。なので、進めます。後で、認証が混乱したように壊れます。 モバイル認証の不一致の説明その設計は正解です。モバイルアプリまたはElectronバンドルは安全なシークレットストアではありません。
機能するもの:
何が機能する: 機能しないもの:
モバイルアプリ用にWebクレデンシャルを作成して、実装にシークレットを強制すること __CAPGO_KEEP_0__ チームにとって、これは通常、2 つの悪いパターンのいずれかで表現されます:
For Capacitor teams, this usually shows up in one of two bad patterns:
- アプリはブラウザベースのフローを使用して、 ウェブクライアント を起動し、次に秘密のサーバーとして振る舞うようにします。
- アプリは クライアントシークレット をバンドル内のcodeから送信しますが、これはシークレットが秘密であることを意味することの逆です。
より良いアプローチは、モバイルとデスクトップアプリを パブリッククライアントとして扱うことです。
FirebaseバックアップのAndroidサインインのもう一つの重要な点は、Google Client IDの設定が必要です。 もう一つの微妙な点は、Firebase-backed Androidサインインの場合に重要です。その設定では、 ウェブアプリケーションタイプのクライアントID
もし1つのルールを覚えたいなら、次の1つを覚えておけ: クライアントの種類を選択する際は、codeが実行される場所に合わせて選択し、必要なクレデンシャル形状とは関係なく.
APIのGoogle認証情報のセキュリティ
OAuthの多くのインシデントは、複雑な攻撃ではなく、チームがクレデンシャルを漏洩させたり、リダイレクト設定を過度に拡大させたり、または秘密情報を安全でない場所に保存したりしたことによるものである。
GoogleのOAuthガイドラインでは、クライアントIDとシークレットをプライベートデータとして扱うことを強調しており、WebアプリケーションではクライアントIDは事前に登録されたリダイレクトURIと厳密に一致する場合にのみ有効である。リダイレクトURIが厳密に一致しない場合、Googleはリクエストを拒否する。リダイレクトURIの起源バインディングは、OAuth.comのクライアント登録ガイドラインで説明されているように、トークンを盗聴する保護のうちの一部である。 OAuth.comのクライアント登録ガイドライン.
あまり多くはしなくても、次の2つだけを正しく行えば十分である。
__CAPGO_KEEP_0__にクライアントシークレットを配布しないこと。
- Never ship a client secret in app code. 厳密なリダイレクトURIを登録すること。
- リダイレクト URI を正確に登録してください。 十分に満足ではありません。Googleはウェブフローの厳密な一致を検証します。
- 起源をきつく抑えます。 便宜上の理由で、広範なドメインを認可しないでください。
- プラットフォームのクレデンシャルを分離してください。 Android、iOS、ウェブを一つのクレデンシャルに合わせてはなりません。
1 つの運用上の詳細は、簡単に誤解を招く可能性があります。Googleは、既存のクライアントIDに対して新しいシークレットを生成し、古いものを無効化することを許可しています。それは、シークレットが漏洩した場合や、デプロイメントプロセスを強化する場合に重要です。
セキュアなチームの実際の行動
セキュアなチームは、OAuthクレデンシャルを他のプロダクションシークレットと同様に扱います。
ウェブクライアントシークレットをバックエンドで保持し、環境管理を通じてインジェクトし、コンソールへのアクセスを監査することが重要です。リリースパイプラインを整理する際に、このガイド CI/CDパイプラインでシークレットを管理する方法 を認可設定にも適用する価値があります。
また、メタデータをレビューすることも重要です。クライアントIDは、ユーザーが見るアプリケーション名と関連しています。アプリケーション名が曖昧または誤解を招く場合は、ユーザーは信頼できないプロンプトまたは誤ったアプリケーションを承認する可能性が高くなります。
セキュリティは、秘密を隠すことだけではありません。正しいアプリのアイデンティティ、リダイレクトのターゲット、承認画面が毎回一致するようにすることも含まれます。
クライアントIDのエラーをトラブルシューティングする
ほとんどのGoogle OAuthの失敗は、設定ミスによるものです。エラーテキストは親切ではありませんが、根本的な問題は、どこに目を向けるかを知ることで簡単に解決できます。
ほとんどの失敗を解決する修正
redirect_uri_mismatch
アプリが登録されているウェブクライアントのURIに完全に一致しないリダイレクトURIを送信していることです。スキーム、ホスト、パス、末尾の差異を確認してください。ウェブOAuthでは、厳密な一致がセキュリティモデルの一部です。
invalid_client
この場合、アプリが間違ったクライアントID、間違ったシークレットを送信している、またはプラットフォームをまたがってクレデンシャルを混在させている可能性があります。AndroidまたはiOSフローが間違った場所でウェブクレデンシャルを使用していることがよくあります。
invalid_request
この点は広いですが、クロスプラットフォームアプリでは、多形化された認証パラメータや、クライアントタイプに合わないフローが原因となることがよくあります。アプリがシークレットを含めるべきところで含めていないか、選択したOAuthフローが異なる種類のクライアントを想定しているかを確認してください。
Google Sign-Inはウェブで動作しますが、モバイルでは失敗します。
最初に調べるべきことはクライアントタイプです。モバイル開発者にとって最も一般的なエラーの原因は、ウェブアプリケーションクライアントIDを作成してクライアントシークレットを取得したいだけにしていることです。実際には、AndroidまたはiOSタイプを使用する必要があります。これらのタイプは、シークレットを意図的に省略することがよくあります。 クライアントシークレットの不一致の解説. ご実装にトークンライフサイクルワークが含まれる場合、削除ガイドも有用です。
Androidのサインインが失敗した
Androidクライアントに紐づいたSHA1のハッシュ値を確認してください。サインインの際に使用する署名情報がGoogleの期待どおりになっていない場合、正しい所有権を証明できません。
Consent画面が不正確
OAuth設定画面で設定されているアプリ名とブランド名を確認してください。ユーザーはそこで表示されているものを許可するので、不正確なメタデータは信頼性の低下とサポートの混乱を引き起こします。
実際のデバッグの順序は簡単です。 まずクライアントタイプを確認し、次にリダイレクト設定、プラットフォーム識別子、最後にシークレットがフローに含まれるべきかどうかを確認してください。.
チームがCapacitorまたはElectronアプリを配信する場合、認証のバグはほとんどの場合、孤立してしまわないことが多いです。 それらは通常、リリースの圧力、ロールバックの必要性、環境固有の修正とともに表面化します。 Capgo helps teams ship targeted updates to app code and assets without waiting on store review, which makes it much easier to correct login flows, callback handling, and client-side auth issues when they slip into production.
