Google Sign-Inの簡単な統合を期待していましたが、クレデンシャル画面に直面しています。なぜ一つのアプリタイプではクライアントシークレットが提供され、もう一方では提供されないのでしょうか。実際には、クライアントシークレットが提供されないアプリタイプは、Capacitor、Ionic、Electron、または混合Webとネイティブのスタックを使用して構築している場合に、混乱は正常です。
実装を実際に実行する部分は、ほとんどのガイドが省略しています: Google Client IDsはプラットフォーム固有のもの, そして非Webアプリの種類は は しない
間違ったクレデンシャルを作成して、秘密をフローに強制するだけでは、通常、OAuth設定が壊れてデバッグが困難になる
Google エコシステムにアプリを接続する
多くのチームは同時にこの問題に直面します。 Googleでサインイン それとも、ユーザーがドライブやカレンダーなどのアクセスを承認したい場合、突然APIキーが十分ではなくなってしまう。
それは、ユーザー認証と委任されたアクセスがOAuthを通じて実行されるためです。Googleには、 アプリケーションを識別するための方法が必要です。 APIが呼び出されているだけではありません。 Google Client IDというクレデンシャルがその役割を果たします。.
複数のプラットフォームでコードベースを共有している場合、混乱がさらに速く進みます。ウェブフロントエンド、Androidシェル、iOSアプリ、デスクトップ用のElectronビルドなど、さまざまなアプリケーションが存在する可能性があります。製品ブランドとバックエンドロジックを共有するかもしれませんが、すべてが同じOAuth IDを共有するべきではありません。
実用的なOAuth設定は、以下の実装に関する質問に回答することで実現されます。
- どのようなアプリケーションタイプを作成するか
- クライアントシークレットが必要か
- どのリダイレクトURIまたはオリジンが厳密に一致する必要があるか
- モバイルとウェブフローのワイヤリングを実行する方法は何か、クレデンシャルを混ぜないようにする方法は何か
- Why a flow that works in the browser fails inside a native wrapper
実用的なルール: アプリがユーザーの許可またはサインインを求めている場合、OAuthクライアントのタイプを考慮するのではなく、API キーを考慮するのではなく、始めてください。
その区別は早期に時間を節約するだけでなく、コンソールがより多くのフィールドを表示しているため、ウェブ認証情報を基にモバイルログインフローを構築する一般的な間違いを防ぐこともできます。 Capacitor アプリを実装している場合、このガイド OAuth2 in Capacitor apps はアプリ側のフローとともに、有用な相談相手です。
What Is a Google Client ID
A Google OAuth 2.0 client ID はGoogleの認証システムにおけるアプリケーションの公的識別子です。Googleは、Google認証エンドポイントからアクセストークンを要求する際のアプリケーションのユニークなユーザー名として説明し、API キーと区別し、OAuthフローでトークン交換中にアプリのアイデンティティを検証するために使用されることを指摘しています。 Google CloudのOAuthクライアントドキュメント.
シンプルな認識モデル
アプリケーションを想像してください クライアントIDGoogle 問題はアプリケーションの 公開ユーザー名.
Googleに「このリクエストは、この登録済みアプリケーションから来ています」と伝えます。
サインイン、同意、トークン交換、ユーザーを代表してアプリが行動を求めるすべてのフローで、このクライアントIDは重要です。
クライアントIDは、アプリとGoogleの認証サーバー両方で参照されるように設計されています。 この資格情報が混乱を招くのは、2つの概念が入れ替えられないことです。
API key identifies a project for certain API calls that don’t involve delegated user authorization.
__CAPGO_KEEP_0__キー は、秘密情報を安全に保持できるフローとアプリタイプのみで使用される機密情報の対称値です。
多くの不完全な統合は、誰かがこれらを同じものとして扱うときに始まります。そうではありません。
クライアントIDGoogleの実際の位置
あなたが必要とする Googleでサインイン または Capacitorライブアップデートの代替品の比較ページCapawesomeの比較ページ
コンサルティングサービスページ
Appflowの比較/移行マーケティングコピー
- Appflowの比較/移行マーケティングコピー
- Appflowの比較/移行マーケティングコピー
- 正しいアプリの種類を使用して、シークレットがフローに含まれるかどうかを判断する
アプリのアイデンティティと委任されたアクセスがどのように関連しているかについてのより広範な概要を知りたい場合は アプリの認可のガイド このガイドは、再度確認するのに役立ちます。
クライアント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, または デスクトップ. その選択は外観的なものではなく、どのアプリが識別され、どのようなサポート設定が必要になるかを定義します。
ウェブアプリの場合、次の値を入力することを予想してください:
- 認可されたJavaScriptのオリジン
- 認可されたリダイレクトURI
その値は厳密に一致する必要があります。ウェブクレデンシャル用には、フルスキームとホスト名を含む、以下のようになります: https://www.example.com, ではなく、曖昧なドメイン概念を使用しないでください。
モバイルプラットフォームの場合、形状は異なります。Androidの登録にはパッケージレベルのアイデンティティと所有権の検証が必要です。一方、iOSは独自のプラットフォーム識別子を使用します。Google認証を他の認証層と組み合わせる場合、 このCapacitorのソーシャルログイン設定は、Supabaseの例として、こうした要素がどのように組み合わさるかを示しています。 Android
このガイドは、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 ウェブアプリ, an Android ビルド, an iOS ビルド, and a デスクトップ アプリ 同じセキュリティ特性を提示しない。同様に、同様に、すべてのプラットフォームが信頼できる環境でクレデンシャルを保存していない。Google はそれを解決するために、各プラットフォームに独自のアプリ登録モデルを提供します。
その分離は、セキュリティ上の良い衛生です。1 つのプラットフォームのクレデンシャル設定が侵害または不正設定されている場合、他のプラットフォームは自動的に露呈されません。
ここでは、実際的な分割を以下に示します。
- Web Web クライアント ID と厳格なオリジンとリダイレクト URI マッチングを使用します。
- Android AndroidクライアントIDはパッケージのIDとSHA1の指紋に紐付けられます。
- iOS iOSクライアントIDはアプリのバンドルIDに紐付けられます。
- DesktopまたはElectron DesktopスタイルのOAuthパターンが秘密のブラウザフローではなく使用されることが多い。
GoogleクライアントIDの種類の比較
| アプリケーションタイプ | 主な識別子 | クライアントシークレットを提供するか? | 主な用途 |
|---|---|---|---|
| Web | 認可されたJavaScriptのオリジンとリダイレクトURI | 通常はいはい | ブラウザアプリとバックエンドアシストウェブOAuth |
| Android | パッケージIDプラスSHA1フィンガープリント | よくない | ネイティブAndroidログイン |
| iOS | アプリバンドルID | よくない | ネイティブiPhoneとiPadログイン |
| デスクトップ | インストール済みアプリID | しばしばない | デスクトップアプリ、Electronスタイルのネイティブフローを含む |
モバイルとデスクトップ向けのクライアントシークレットのジレンマ
この部分は、多くのチュートリアルが間違っている。
モバイルとデスクトップ向けの開発者は、OAuthクライアントが両方の クライアントID と クライアントシークレットを含むことを期待することがよくあります。 その後、コンソールでシークレットを表示できるように、Webアプリケーション資格情報を作成します。 フローはより完成度が高く見え、開発者はそのまま進みます。 しかし、後で認証が混乱した状態で破壊されることがあります。 によると credential because that’s the only way they can see a secret in the console. The flow looks more complete, so they keep going. Later, authentication breaks in confusing ways.
According to モバイル認証の不一致の説明非Webアプリケーションの種類であるAndroid、iOS、インストール済みアプリなどは、Googleがユーザーが秘密情報を抽出できるクライアント側ソフトウェアに秘密情報を埋め込まないようにしたため、意図的にクライアントIDのみを受け取ることが多い。
その設計は正しい。モバイルアプリまたはElectronバンドルは安全な秘密情報の保存場所ではない。
これが機能する: パブリッククライアント向けに設計されたネイティブまたはクライアントサイドのOAuthフロー。
これが機能しない: モバイルアプリにWeb認証情報を作成して、実装に秘密情報を強制すること。
これはCapacitorチームにとって、通常、2つの悪いパターンのいずれかで表現される。
- アプリはブラウザベースのフローを実行するために Webクライアント を使用し、次に秘密情報を含まないようにするために
- 秘密情報を含まないようにするために クライアント シークレット バンドルされた code から、秘密が隠されていることを意味することになる。
より良いアプローチは、モバイルアプリとデスクトップアプリを パブリック クライアントとして扱うことです。
現代の OAuth では、一般的に秘密がクライアント内に隠されていることを依存しないフローを使用する必要があります。バックエンドが関与している場合、秘密を隠す必要のないオペレーションはバックエンドに保管し、ネイティブ アプリはパブリック クライアントが実行できるようにする必要があります。 Firebase-backed Android サインインのもう一つの微妙な点は、Android アプリが独自のプラットフォーム固有のアイデンティティを保持するのに対して、ウェブ アプリケーション タイプ クライアント ID がバックエンド サーバーの OAuth クライアント ID として使用されるということです。 Android アプリは、ウェブ アプリケーション タイプ クライアント ID と同じプロジェクト内で両方のクレデンシャルを認識するため、チームは両方のクレデンシャルが互いに置き換えられるものと思い込むことがよくありますが、実際にはそうではありません。両方は異なる役割を果たします。
1 つのルールを覚えておくなら、次のルールを覚えておくことをお勧めします。 クライアントのタイプを選択する際は、code が実行される場所に合わせて選択し、望ましいクレデンシャル形状に合わせて選択しないことです。.
Google API のセキュリティ
OAuth の多くのインシデントは、複雑な攻撃ではなく、チームがクレデンシャルを漏洩させたり、リダイレクト設定を過度に広範囲に設定したり、秘密を安全でない場所に置いたりすることによって引き起こされることが多いです。
GoogleのOAuthガイドラインでは、クライアントIDとシークレットをプライベートデータとして扱うことを強調しており、WebアプリケーションではクライアントIDは事前に登録されたリダイレクトURIと厳密に一致するように強制されています。リダイレクトURIが厳密に一致しない場合、Googleはリクエストを拒否します。このオリジンバインディングは、OAuth.comのクライアント登録ガイドラインで説明されているトークンインテリセプションの保護の一部です。 OAuth.comのクライアント登録ガイドライン.
Whatを即座にロックダウンする
何をしなければならないかを理解する
- アプリを配信する際に、クライアントシークレットを code に含めることは絶対にしない。 Webバンドル、モバイルバイナリ、Electronパッケージはユーザーによってインスペクトできる。
- 厳密に一致するリダイレクトURIを登録する。 「十分に近い」は十分ではない。GoogleはWebフローにおける厳密な一致を検証する。
- オリジンを絞り込む。 セットアップのフリクションを回避するために、広いドメインに認可しない。
- プラットフォームクレデンシャルを分離する。 Android、iOS、ウェブを1つの資格情報に押し付けるのはやめよう。
Googleは、既存のクライアントIDに対して新しいシークレットを生成し、古いものを無効化できるチームを許可しています。これは、シークレットが漏洩した場合や、デプロイメントプロセスを強化している場合に重要です。
セキュアなチームが実際に何をするか
トラブルを避けるチームは、OAuth資格情報を他のプロダクションシークレットと同様に扱います。
ウェブクライアントシークレットはバックエンドで保管し、環境管理を通じてインジェクトし、コンソールへのアクセスを監査します。リリースパイプラインを整理している場合、このCI/CDパイプラインにおけるシークレットの管理に関するガイド は、認証設定にも適用する価値があります。 また、メタデータをレビューすることも行います。クライアントIDはOAuth承認画面に表示されます。アプリケーション名が曖昧または誤解を招く場合は、ユーザーは信頼できない画面または誤ったアプリケーションを承認する可能性が高くなります。
セキュリティはシークレットを隠すことだけではなく、正しいアプリケーションID、リダイレクトターゲット、承認画面が毎回一致するようにすることにもある。
クライアントIDのエラーの一般的なトラブルシューティング
Google OAuthの失敗のほとんどは、設定ミスによるものです。エラーテキストは優しくないかもしれませんが、問題の根本原因は、どこに注目すればよいかを知っている場合に簡単に分かります。
ほとんどの失敗を解決するための修正
ほとんどの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 のハッシュ値をもう一度確認してください。署名の ID が 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.
