Google Sign-Inの統合が簡単なはずですが、クレデンシャル画面にたどり着いて、クライアントシークレットが提供されないアプリタイプが原因で混乱するのは当然のことです。Capacitor、Ionic、Electron、または混合Webとネイティブのスタックで開発している場合、特にそうです。
実装が破綻するのは、ほとんどのガイドが省略している部分です: Google Client IDはプラットフォーム依存、および非Webアプリのタイプは は しない
間違ったクレデンシャルを作成して秘密鍵を強制するだけでは、通常、OAuth設定が壊れてデバッグが困難になる
- 目次
- アプリをGoogleエコシステムに接続する
- クライアントIDの実践における位置付け
- プラットフォーム固有のクライアントID設定
- Google API の資格情報をセキュアにする
- クライアントIDのエラーをトラブルシューティング
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__キー は、秘密の対称点であり、安全にシークレットを保持できるフローとアプリタイプのみで使用されます。
A lot of broken integrations start when someone treats these as variations of the same thing. They aren’t.
クライアント ID Google の実際の位置
あなたが必要とする Google でサインイン または Capacitor のライブアップデートの代替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クライアントクレデンシャルを作成するためのノートパソコンのキーボードを入力する人物 クライアントIDを作成して表示する方法.
コンソールエリアで始めましょう
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.
認証情報を作成する際は、自分を閉じ込めることなく
認証情報を作成する際の最大の決定は、 アプリケーションタイプです。Googleは、特定のタイプを選択するように求めます。たとえば、 Web, Android, iOS, または デスクトップ. その選択は外観的なものではなく、どのアプリが識別され、どのようなサポート設定が必要になるかを定義します。
ウェブアプリの場合、次の値を入力することを予想してください:
- 認可されたJavaScriptのオリジン
- 認可されたリダイレクトURI
その値は厳密に一致する必要があります。ウェブ認証の場合、Googleはフルスキームとホスト名を含む完全なものを期待します。たとえば https://www.example.com、ではなく、汚いドメインの概念を使用するのではなく。
モバイルプラットフォームの場合、形状は異なります。Androidの登録にはパッケージレベルのアイデンティティと所有権の検証が必要です。一方、iOSは独自のプラットフォーム識別子を使用します。Google認証を他の認証層と組み合わせる場合、 このCapacitorのソーシャルログイン設定は、Supabaseと組み合わせることで、これらの要素がどのように組み合わさるかを示す便利な例です。 is a useful example of how these pieces often fit together.
このガイドは、クリックして UI を比較したい場合は、視覚的な参照として十分です。
後でどこで見つけるか
クライアント ID の作成後、プロジェクトのクレデンシャルリストに表示されます。同様のプロジェクトスペースは、チームが API を有効化し、OAuth の IDENTITY が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アプリケーション の資格情報を作成します。フローは完成したように見えますので、開発者は進めます。後で、認証が混乱したように失敗します。
According to モバイル認証の不一致の説明非Webアプリケーションの種類であるAndroid、iOS、インストール済みアプリなどは、Googleがユーザーが秘密情報を抽出できるクライアント側ソフトウェアに秘密情報を埋め込まないようにしたため、意図的にクライアントIDのみを受け取ることが多い。
その設計は正しい。モバイルアプリまたはElectronバンドルは秘密情報の安全なストレージではありません。
何が機能するか: パブリッククライアント向けに設計されたネイティブまたはクライアントサイドのOAuthフロー。
何が機能しないか: モバイルアプリにWeb認証情報を作成して、実装に秘密情報を強制すること。
Capacitor チームにとって、これは通常、2 つの悪いパターンのいずれかで表現される。
- アプリはブラウザベースのフローを開始し、Webクライアントを使用し、次に秘密情報を含まないようにするために秘密のサーバーと振る舞う。 アプリは 秘密情報を含まないようにするために秘密のサーバーと振る舞う。
- アプリは クライアントシークレット バンドルされたcodeから、シークレットが隠されていることを認識することの意味を否定する。
より良いアプローチは、モバイルアプリとデスクトップアプリを パブリッククライアントとして扱うことです。
現代のOAuthでは、パブリッククライアントを使用することが一般的です。クライアントにシークレットが含まれていることを隠す必要がないためです。バックエンドが関与する場合は、秘密情報をバックエンドに保持し、ネイティブアプリはパブリッククライアントが実行できるようにする必要があります。 Firebase-backed Androidのサインインのもう一つの微妙な点は、 ウェブアプリケーションタイプクライアントID
はバックエンドサーバーのOAuthクライアントIDとして使用され、Androidアプリは独自のプラットフォーム固有のアイデンティティを保持します。この分離はチームが両方のクレデンシャルを同じプロジェクト内で見るため、混乱を招きます。1つが他を置き換えるものだと思ってしまいますが、実際にはそれらは異なる役割を果たします。 choose the client type that matches where the code runs, not the credential shape you wish you had.
クライアントタイプを選択する際は、APIが実行される場所を考慮し、望ましいクレデンシャル形状と一致するものを選択するのではなく、実際に実行されている場所を考慮することです。
Google __CAPGO_KEEP_0__のシークレットを保護する方法
GoogleのOAuthガイドラインでは、クライアントIDとシークレットをプライベートデータとして扱うことを強調しており、WebアプリケーションではクライアントIDは事前に登録されたリダイレクトURIと厳密に一致することを確認します。リダイレクトURIが厳密に一致しない場合、Googleはリクエストを拒否します。このオリジンバインディングは、OAuth.comのクライアント登録ガイドラインで説明されているトークンインテリセプションの保護の一部です。 OAuth.comのクライアント登録ガイドライン.
すぐにロックダウンするべきもの
何をしてでも、これだけを正しく行うこと:
- Never ship a client secret in app code. Webバンドル、モバイルバイナリ、Electronパッケージはユーザーによってインスペクトできる。
- 厳密なリダイレクトURIを登録すること。 「十分に近い」は十分ではありません。GoogleはWebフローで厳密な一致を検証します。
- オリジンを狭くすること。 セットアップのフリクションを回避するために広いドメインを許可しないこと。
- プラットフォームクレデンシャルを分離すること。 Android、iOS、ウェブを1つの資格情報に押し付けるのはやめよう。
Googleは、既存のクライアントIDに対して新しいシークレットを生成し、古いものを無効化することを許可している。そういったことは、シークレットが漏洩した場合や、デプロイメントプロセスを強化している場合に重要になる。
セキュアなチームが実際に何をしているか
トラブルを避けたいチームは、OAuth資格情報を他のプロダクションシークレットと同じように扱う。
ウェブクライアントシークレットはバックエンドで保管し、環境管理を通じてインジェクトし、コンソールへのアクセスを監査する。 リリースパイプラインを整理している場合、このCI/CDパイプラインにおけるシークレットの管理に関するガイド は、認証設定にも適用する価値がある。
チームは、キーだけではなく、メタデータをレビューすることも行う。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 のタイプを使用する必要があります。これらのタイプは、シークレットを意図的に省略することがよくあります。これについては、クライアント シークレットの不一致の解説で説明されています。 シークレットの不一致の解説token ライフサイクルワークを含む実装の場合、サインイン後に revocation guide は有用です。
Android のサインインがクレデンシャル作成後に失敗します。
Android クライアントに付属している SHA1 フィンガープリントをもう一度確認してください。署名の ID が Google の期待どおりになっていない場合、アプリは正当な所有権を証明できません。
Consent スクリーンが不正確です。
OAuth設定のコンソールで確認するアプリ名とブランドを確認してください。ユーザーはそこで見たものを承認するので、不正なメタデータは信頼性の問題とサポートのノイズを生じます。
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.
