Cloud Endpoints 支持多种身份验证方法，这些方法适用于不同的应用和使用场景。Extensible Service 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 令牌 (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"]],["最后更新时间 (UTC)：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)."]]
