Cloud Endpoints 支援多種適合不同應用程式和用途的驗證方式。可擴充服務 Proxy (ESP) 採用您在服務設定中指定的驗證方式，用於在將傳入要求傳送到您的 API 後端之前進行驗證。本文件針對每種支援的驗證方式提供概覽及用途範例。
API 金鑰
API 金鑰是一種加密字串，用於識別Google Cloud 專案的配額、帳單及監控等功能。開發人員會在 Google Cloud 主控台的專案中產生 API 金鑰，然後將該金鑰以查詢參數的形式，嵌入在對 API 發出的每一個呼叫中。
如果您在服務設定中指定 API 金鑰需求，ESP 會使用該 API 金鑰查詢與該 API 金鑰相關聯的 Google Cloud 專案。除非該 API 金鑰是在 Google Cloud 專案中或在已啟用您 API 的其他Google Cloud 專案中產生的，否則 ESP 會拒絕要求。詳情請參閱「透過 API 金鑰限制 API 存取權」一文。
不同於使用短期憑證或簽署要求的憑證，API 金鑰是要求的一部分，因此容易遭受中間人攻擊，安全程度較低。除了下列所述的驗證方法，您還可以使用 API 金鑰。基於安全考量，當 API 呼叫包含使用者資料時，請勿單獨使用 API 金鑰。
用途
如果您想要使用如配額之類的 Endpoints 功能，則必須使用 API 金鑰傳送每個要求，Endpoints 才可以識別與用戶端應用程式相關聯的 Google Cloud 專案。
使用 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-09-04 (世界標準時間)。"],[[["\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)."]]
