このページでは、一般的な認証と認可のユースケースを示します。また、各ユースケースの実装方法に関する情報へのリンクも示します。
Google での認証の概要については、Google での認証をご覧ください。
Google API の認証
Google API では、リクエストごとに有効なアクセス トークンまたは API キーが必要です。これらの必要な認証情報を指定する方法は、コードが実行されている場所と、API で受け入れられる認証情報の種類によって異なります。
クライアント ライブラリとアプリケーションのデフォルト認証情報を使用する
Google API の使用には、クライアント ライブラリとアプリケーションのデフォルト認証情報（ADC）を使用することをおすすめします。Application Default Credentials (ADC) は、アプリケーション環境に基づいて認証情報を自動的に検索するために認証ライブラリが使用するストラテジです。認証ライブラリは、これらの認証情報を Cloud クライアント ライブラリと Google API クライアント ライブラリで使用可能にします。ADC を使用すると、Google Cloud サービスと API に対するアプリケーションの認証方法を変更せずに、開発環境または本番環境でコードを実行できます。
ADC の設定方法は、コードの実行場所によって異なります。ADC は、サービス アカウントとしての認証とユーザーとしての認証の両方をサポートしています。
Google Kubernetes Engine（GKE）から認証する
Workload Identity Federation for GKE を使用して、GKE 上で実行されているワークロードが Google API に安全にアクセスできるようにします。Workload Identity Federation for GKE を使用すると、GKE クラスタ内の GKE サービス アカウントが Identity and Access Management（IAM）サービス アカウントとして機能します。
Knative serving から認証する
Knative serving サービスを認証するには、Workload Identity Federation for GKE を使用します。これにより、Google API にアクセスできるようになります。
API キーを受け取る API を使用する
API キーは、請求と割り当てを目的として API リクエストを Google Cloud プロジェクトに関連付けます。API が API キーをサポートしている場合、API リクエストでは、トークンの代わりに API キーを指定できます。API が API キーをサポートしているかどうかを確認するには、該当する API のドキュメントをご覧ください。
自己署名 JSON ウェブトークン（JWT）を使用する
一部の Google API は、アクセス トークンの代わりに自己署名 JSON ウェブトークン（JWT）をサポートしています。自己署名 JWT を使用すると、Google の認可サーバーへネットワーク リクエストを行う必要がなくなります。このアプローチでは、独自の署名付き JWT を作成する必要があります。トークンの詳細については、トークンの種類をご覧ください。
認証ライブラリとパッケージを使用する
環境内で ADC と Cloud クライアント ライブラリまたは Google API クライアント ライブラリの OAuth 実装を利用できない場合は、認証ライブラリとパッケージを使用できます。
次の認証ライブラリとパッケージを使用できます。
Google の OAuth 2.0 エンドポイントを使用して、OAuth 2.0 フローを実装することもできます。このアプローチでは、OAuth 2.0 と OpenID Connect の仕組みをより深く理解する必要があります。詳しくは、ウェブサーバー アプリケーションに OAuth 2.0 を使用するをご覧ください。
Google Cloud サービス固有のユースケース
一部の Google Cloud サービスは、サービス固有の認証フローをサポートしています。
署名付き URL を使用して Cloud Storage リソースへの期限付きアクセスを提供する
署名付き URL では、特定の Cloud Storage リソースへの期限付きアクセスが提供されます。
GKE Enterprise クラスタに対する認証
GKE Enterprise クラスタに対する認証には、Google Cloud ID またはサードパーティの ID プロバイダを使用できます。
- Connect ゲートウェイを使用して Google Cloud ID で認証する。
- Anthos Identity サービスを使用して、OIDC または LDAP をサポートするサードパーティの ID プロバイダで認証する。
API Gateway または Cloud Endpoints を使用してデプロイされる認証用の API を構成する
API Gateway と Cloud Endpoints は、サービス間認証と、Firebase、Google 署名付き ID トークン、Okta、Auth0、JWT によるユーザー認証をサポートしています。
詳細については、各プロダクトのドキュメントをご覧ください。
Cloud Run または Cloud Run functions でホストされているアプリケーションの認証
Cloud Run と Cloud Run functions でホストされるアプリケーションでは、認証に OpenID Connect（OIDC）トークンまたは ID トークンが必要です。
詳細については、下記のホスティング サービスのプロダクト ドキュメントをご覧ください。ID トークンを取得するほかの方法については、ID トークンを取得するをご覧ください。ID トークンの検証など、ID トークンの詳細については、ID トークンをご覧ください。
Cloud Run
Cloud Run サービスの設定は、サービスの呼び出し方法によって異なります。Cloud Run サービスから他のサービスに対する認証も必要になる場合があります。その場合、OIDC ID トークンが必要になります。
ウェブアプリやモバイルアプリからサービスへのユーザーを認証するには、Identity Platform または Firebase Authentication を使用します。Identity-Aware Proxy（IAP）を使用して内部ユーザーを認証することもできます。
Cloud Run functions
関数を呼び出すときは、呼び出しを認証する必要があります。ユーザー認証情報または OIDC ID トークンを使用できます。
アプリケーション ユーザーの認証
アプリケーションのエンドユーザーを認証する方法は、残りのアプリケーション環境によって異なります。以下の説明を使用して、アプリケーションに最適なオプションを理解してください。
| 認証サービス | 説明 |
|---|---|
| Google Identity Services |
Google Identity Services には、Google でログイン、Google のユーザー ログインボタン、Identity Services API と SDK が含まれています。Google Identity Services は、OAuth 2.0 と OpenID Connect（OIDC）プロトコルに基づいています。 モバイルアプリを作成しており、Gmail アカウントと Google Workspace アカウントを使用してユーザーを認証したい場合は、「Google でログイン」が適しています。「Google でログイン」では、既存のログイン システムで Google アカウントを使用できます。 詳細 「Google でログイン」は、Gmail や Google Workspace アカウントのログインを提供し、ワンタイム パスワード（OTP）をサポートします。「Google でログイン」は、Google のみのアカウント、または既存のログイン システムの Google アカウントを対象とします。 「Google でログイン」は、iOS、Android、ウェブ アプリケーションで使用できます。 |
| Firebase Authentication |
Firebase Authentication には、さまざまな種類のユーザー アカウント タイプについて、アプリケーションの認証を行う認証サービスとライブラリが用意されています。 複数のプラットフォームからのユーザーのログインを受け入れる場合は、Firebase Authentication を使用することをおすすめします。 詳細 Firebase Authentication は、多くのユーザー アカウント タイプの認証機能を備えています。Firebase Authentication はパスワード認証のほか、Google、Facebook、Twitter などのプラットフォームと連携したログインをサポートしています。 Identity Platform と Firebase Authentication はどちらも Google Identity Services に基づいています。Firebase Authentication は、一般ユーザー向けのアプリケーションを対象としています。Identity Platform は、独自の ID プロバイダを使用するユーザーや、Identity Platform で提供されるエンタープライズ対応機能を必要とするユーザーに最適です。これらのプロダクトの違いについて詳しくは、Identity Platform と Firebase Authentication の違いをご覧ください。 詳しくは、次のリンクをご覧ください。
|
| Identity Platform |
Identity Platform は、エンタープライズクラスの ID とアクセス管理機能を自社アプリケーションに組み込むための顧客 ID とアクセス管理（CIAM）プラットフォームです。 Google Workspace などの Google ID プロバイダで使用するアプリケーションや、独自の Identity and Access Management サービスを使用するアプリケーションを作成する場合は、Identity Platform の使用をおすすめします。 詳細 Identity Platform は、ユーザーの登録とログインを管理するカスタマイズ可能なドロップイン ID と認証サービスを提供します。Identity Platform は、さまざまな認証方法（SAML、OIDC、メールアドレスとパスワード、ソーシャル、スマートフォン、カスタム オプション）をサポートしています。 Identity Platform と Firebase Authentication はどちらも Google Identity Services に基づいています。Firebase Authentication は、一般ユーザー向けのアプリケーションを対象としています。Identity Platform は、独自の ID プロバイダを使用するユーザーや、Identity Platform で提供されるエンタープライズ対応機能を必要とするユーザーに最適です。これらのプロダクトの違いについて詳しくは、Identity Platform と Firebase Authentication の違いをご覧ください。 |
| OAuth 2.0 と OpenID Connect |
OpenID Connect を使用すると、大部分のカスタマイズで認証トークンを処理し、使用できます。 OAuth 2.0 実装を完全に制御したいと考えており、OAuth 2.0 フローの実装に慣れている場合は、このオプションを検討してください。 詳細 Google の OAuth 2.0 実装は OpenID Connect 仕様に準拠しており、OpenID Certified となっています。OpenID Connect は OAuth 2.0 プロトコルの上にある ID レイヤです。アプリケーションは、OpenID Connect を使用して ID トークンを検証し、ユーザー プロフィール情報を取得できます。 OAuth 2.0 を使用すると、Identity-Aware Proxy で保護されたリソースにプログラムで認証を実装できます。 |
| Identity-Aware Proxy（IAP） |
IAP を使用すると、リクエストがアプリケーション リソースに到達する前にアプリケーションへのアクセスを制御できます。 アプリケーション内に実装されたこのテーブルの他の認証サービスとは異なり、IAP はアプリケーションに到達する前に認証を実行します。 詳細 IAP を使用すると、アプリケーションの一元的な認可レイヤを確立し、署名済みヘッダーを使用してアプリを保護できます。IAP で保護されたアプリケーションにアクセスできるのは、正しい IAM ロールを持つプリンシパルだけです。エンドユーザーが IAP で保護されたリソースにアクセスしようとすると、IAP が認証と認可のチェックを行います。IAP は、同じプロジェクト内の別のサービスなど、同じプロジェクトのアクティビティから保護することはありません。 Google ID の場合、IAP は ID トークンを使用します。詳細については、プログラムによる認証をご覧ください。 IAP がアプリケーション リソースを保護する仕組みについては、IAP の概要をご覧ください。 IAP では、次の言語固有のチュートリアルを利用できます。 |
| App Engine Users API | App Engine スタンダード環境で実行されるアプリケーションの場合、一部の言語では Users API を利用してユーザー認証機能を提供できます。 |
| エンドユーザー リソースへのアクセスの承認 | エンドユーザーが所有するリソースにアプリケーションでアクセスする必要がある場合は、エンドユーザーの権限を確保する必要があります。このユースケースは、アプリケーション、承認サーバー、ユーザーの 3 つのエンティティが関係するため、3-legged OAuth または 3LO と呼ばれることもあります。 |
Google Cloud と Google Workspace の認証と認可のオプション
Google Cloud と Google Workspace には、アクセスの設定、アカウント セキュリティの強化、アカウント管理のためのさまざまなオプションが用意されています。
外部ワークロードに Google Cloud リソースへのアクセス権を付与する
Workload Identity 連携を使用すると、オンプレミスまたはマルチクラウドのワークロードに Google Cloud リソースへのアクセス権を付与できます。従来、このユースケースではサービス アカウント キーの使用が必須でしたが、Workload Identity 連携によりメンテナンスが不要になり、サービス アカウント キー使用時のセキュリティの負担が軽減されます。Workload Identity 連携は、OIDC または SAML 2.0 互換の ID プロバイダをサポートしています。
ID プロバイダを設定する
Cloud Identity または Google Workspace を使用して、Google を ID プロバイダとして使用できます。Cloud Identity アカウントまたは Google Workspace アカウントを外部 ID プロバイダと連携させることもできます。このアプローチでは SAML を使用するため、従業員は既存の ID と認証情報を使用して Google サービスにログインできます。
2 要素認証プロセスを設定する
2 要素認証プロセスを必須にすると、悪意のある人物がアカウントの認証情報にアクセスした際に、そのアカウントにアクセスできないようにできます。2 要素認証プロセスでは、ユーザーを認証する前に、そのユーザーからの 2 番目の情報または ID が必要です。Google は、FIDO（Fast IDentity Online）標準をサポートするいくつかのソリューションを提供しています。
Identity Platform は、ウェブ、iOS、Android アプリの 2 要素認証をサポートしています。
Google Identity Services は、FIDO（Fast IDentity Online）認証をサポートしています。
Google では、Titan キーなど、2 要素認証向けのさまざまなハードウェア ソリューションをサポートしています。
証明書ベースのアクセスを設定する
Chrome Enterprise Premium のゼロトラスト ソリューションの一部である証明書ベースのアクセスは、信頼できるデバイスを使用する認証済みユーザーのみにアクセスを制限し、X.509 証明書によってデバイスを識別します。証明書ベースのアクセスは、mTLS（mutual Transport Layer Security）と呼ばれることもあります。
アカウントと認証に関する一般的な情報
Google アカウントへのアクセスに関するサポート
Google アカウントへのアクセスまたは管理についてサポートが必要な場合は、Google アカウントのサポートページをご覧ください。
漏洩した認証情報への対応
認証情報が漏洩した恐れがある場合は、ユーザーまたは管理者が状況を軽減するための対策を取ることができます。詳細については、不正使用された Google Cloud 認証情報の処理をご覧ください。
認証局の問題についてサポートを利用する
証明書や認証局（CA）に関する問題（ルート CA の問題を含む）に関連するエラーが表示された場合は、Google Trust Services に関するよくある質問をご覧ください。