Cloud Endpoints は、さまざまなアプリケーションや利用方法に適した複数の認証方法をサポートしています。Extensible Service Proxy（ESP）は、サービス構成で指定した認証方法を使用して、受信リクエストを API バックエンドに渡す前に検証します。このドキュメントでは、サポートされる各認証方法の概要と利用方法について説明します。
API キー
API キーは、割り当て、課金、モニタリングのためにGoogle Cloud プロジェクトを識別する暗号化された単純な文字列です。デベロッパーは、Google Cloud コンソールでプロジェクトの API キーを生成し、このキーをクエリ パラメータとしてすべての API 呼び出しに埋め込みます。
サービス構成で API キーを必須として指定すると、ESP はその API キーを使用して、API キーが関連付けられている Google Cloud プロジェクトを検索します。現在お使いの Google Cloud プロジェクトまたは API が有効になっている他のGoogle Cloud プロジェクトで API キーが生成されていない場合、ESP はリクエストを拒否します。詳しくは、API キーで API アクセスを制限するをご覧ください。
Google ID トークンを使用した認証では、ユーザーは Google アカウントでログインすることで認証されます。認証が済むと、ユーザーはすべての Google サービスにアクセスできます。Google ID トークンを使用して、Google API や Endpoints で管理されている API を呼び出せます。ESP は、公開鍵を使用して Google ID トークンを検証し、JWT 内の iss クレームが https://accounts.google.com であることを確認します。
ユースケース
ユーザー全員が Google アカウントを所有している場合は、Google ID トークンを使用した認証が適しています。たとえば、API が Google ドライブ コンパニオンなどの Google アプリケーションに関連付けられていれば、Google ID トークン認証を選択できます。Google ID トークン認証では、ユーザーは Google アカウントでログインすることで認証されます。認証が済むと、ユーザーはすべての Google サービスにアクセスできます。詳しくは、ユーザーの認証の「Google ID トークン」タブをご覧ください。
サービス アカウント
API にリクエストを送信するサービスを識別するには、サービス アカウントを使用します。呼び出し元のサービスは、サービス アカウントの秘密鍵を使用して安全な JSON Web Token（JWT）に署名し、署名した JWT をリクエストに含めて API に送信します。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-25 UTC。"],[[["\u003cp\u003eCloud Endpoints supports various authentication methods, including API keys, Firebase, Auth0, Google ID tokens, and service accounts, each suited to different applications and security needs.\u003c/p\u003e\n"],["\u003cp\u003eAPI keys are simple encrypted strings used for identifying Google Cloud projects for billing, quota, and monitoring, but they are less secure and should not be used alone for API calls involving user data.\u003c/p\u003e\n"],["\u003cp\u003eFirebase authentication, Auth0, and Google ID tokens are recommended when API calls involve user data and are intended for user interface interactions, as they provide more secure user authentication methods.\u003c/p\u003e\n"],["\u003cp\u003eService accounts are ideal for microservices, allowing services to securely identify themselves and communicate with your API using signed JWTs.\u003c/p\u003e\n"],["\u003cp\u003eCustom authentication methods that adhere to the JSON Web Token RFC 7519 standard are also supported for additional flexibility in user authentication.\u003c/p\u003e\n"]]],[],null,["# Choosing an Authentication Method\n\n[OpenAPI](/endpoints/docs/openapi/authentication-method \"View this page for the Cloud Endpoints OpenAPI docs\") \\| gRPC\n\n\u003cbr /\u003e\n\nCloud Endpoints supports multiple authentication methods that are suited\nto different applications and use cases. The\n[Extensible Service Proxy (ESP)](/endpoints/docs/grpc/glossary#extensible_service_proxy)\nuses the authentication method that you specify in your service\nconfiguration to validate incoming requests before passing them to your API\nbackend. This document provides an overview and sample use cases for each\nsupported authentication method.\n\nAPI keys\n--------\n\nAn API key is an encrypted string that identifies a\nGoogle Cloud project for quota, billing, and monitoring purposes. A\ndeveloper generates an API key in a project in the Google Cloud console and\nembeds that key in every call to your API as a query parameter.\n\nIf you specify an API key requirement in your service configuration,\nESP uses the API key to look up the Google Cloud project\nthat the API key is associated with. ESP rejects requests unless\nthe API key was generated in your Google Cloud project or within other\nGoogle Cloud projects in which your API has been enabled. For more\ninformation, see\n\n\n[Restricting API access with API keys](/endpoints/docs/grpc/restricting-api-access-with-api-keys)\n\n\nUnlike credentials that use short-live tokens or signed requests, API keys are a\npart of the request and are therefore considered to be vulnerable to\n[man-in-the-middle attacks](https://wikipedia.org/wiki/Man-in-the-middle_attack)\nand therefore less secure. You can use API keys in addition to\none of the authentication methods described as follows. For security reasons, don't\nuse API keys by themselves when API calls contain user data.\n\n### Use case\n\nIf you want to use Endpoints features such as\n[quotas](/endpoints/docs/grpc/quotas-overview), each request must pass in an API\nkey so that Endpoints can identify the Google Cloud project\nthat the client application is associated with.\n\nFor more information about API keys, see\n[Why and when to use API keys](/endpoints/docs/grpc/when-why-api-key).\n\nFirebase Authentication\n-----------------------\n\n[Firebase Authentication](https://firebase.google.com/docs/auth/)\nprovides backend services, SDKs, and libraries to authenticate users to a mobile\nor web app. It authenticates users by using a variety of credentials such as\nGoogle, Facebook, Twitter, or GitHub.\n\nThe Firebase client library signs a [JSON Web Token\n(JWT)](https://jwt.io/) with a private key after the user successfully\nsigns in. ESP validates that the JWT was signed by\nFirebase and that the `iss` (issuer) claim in the JWT, which identifies\nyour Firebase application, matches the `issuer` setting in the\nservice configuration.\n\n### Use case\n\nWe recommend using Firebase when the API calls involve any user data and\nthe API is intended to be used in flows where the user has a user interface for\nexample, from mobile and web apps.\n\n\nFor more information, see the Firebase tab in\n[Authenticating users](/endpoints/docs/grpc/authenticating-users).\n\n\nAuth0\n-----\n\n[Auth0](https://auth0.com/) authenticates and authorizes applications and APIs\nregardless of identity provider, platform, stack and device.\n\nAuth0 supports a large number of providers and the [Security Assertion Markup\nLanguage](https://wiki.oasis-open.org/security/FrontPage) specification. It\nprovides backend services, SDKs, and user interface libraries for authenticating\nusers in web and mobile apps. Auth0 integrates with several third-party identity\nproviders and also provides custom user account management.\n\nThe client library provided by Auth0 generates and signs a JWT once the user\nsigns in. ESP validates the JWT was signed by Auth0 and that the\n`iss` claim in the JWT, which identifies your Auth0 application, matches the\n`issuer` setting in the service configuration.\n\n### Use case\n\nAuth0 is suited for consumer and enterprise web and mobile apps. For more\ninformation, see the Auth0 tab in\n\n\nFor more information, see the Auth0 tab\n[Authenticating users](/endpoints/docs/grpc/authenticating-users).\n\n\nGoogle ID token authentication\n------------------------------\n\nAuthentication with a\n[Google ID token](/endpoints/docs/grpc/glossary#google_id_token)\nallows users to authenticate by signing in with a Google Account. Once\nauthenticated, the user has access to all Google services. You can use Google ID\ntokens to make calls to Google APIs and to APIs managed by\nEndpoints. ESP validates the Google ID token by\nusing the public key and makes sure that the `iss` claim in the JWT is\n`https://accounts.google.com`.\n\n### Use case\n\nAuthentication with a Google ID token is recommended when all users have Google Accounts. You might choose to use Google ID token authentication, for example,\nif your API accompanies a Google application, such as Google Drive companion.\nGoogle ID token authentication allows users to authenticate by signing in with\na Google Account. Once authenticated, the user has access to all Google\nservices.\n\n\nFor more information, see the Google ID token tab in\n[Authenticating users](/endpoints/docs/grpc/authenticating-users).\n\n\nService accounts\n----------------\n\nTo identify a service that sends requests to your API, you use a\n[service account](/docs/authentication#service_accounts). The calling service\nuses the service account's private key to sign a secure\n[JSON Web Token (JWT)](https://jwt.io/)\nand sends the signed JWT in the request to your API.\n\n### Use case\n\nJWTs and service accounts are well suited for microservices. For more\ninformation, see\n[Authentication between services](/endpoints/docs/grpc/service-account-authentication).\n\nCustom authentication\n---------------------\n\nYou can use other authentication platforms to authenticate users as long as it\nconforms to the JSON Web Token [RFC 7519](https://tools.ietf.org/html/rfc7519).\nFor more information, see the Custom tab in [Authenticating users](/endpoints/docs/grpc/authenticating-users)."]]
