securityDefinitions:your_custom_auth_id:authorizationUrl:""flow:"implicit"type:"oauth2"#Thevaluebelowshouldbeuniquex-google-issuer:"issuer of the token"x-google-jwks_uri:"url to the public key"#Optional.ReplaceYOUR-CLIENT-IDwithyourclientIDx-google-audiences:"YOUR-CLIENT-ID"
security セクションを追加します。API 全体に適用する場合は API レベルに、特定のメソッドに適用する場合はメソッドレベルに追加します。
security:
- your_custom_auth_id: []
OpenAPI ドキュメントでは複数のセキュリティ定義を記述できますが、定義ごとに異なる issuer が必要です。security セクションを API レベルとメソッド レベルの両方で指定した場合、API レベルの設定よりもメソッド レベルの設定が優先されます。
x-google-audiences フィールドは必須ではありません。ESP は、aud クレーム内で https://SERVICE_NAME という形式のバックエンド サービス名を持つすべての JWT を受け入れます。追加のクライアント ID によるバックエンド サービスへのアクセスを許可するには、カンマ区切り値を使用して x-google-audiences フィールドに許可されたクライアント ID を指定します。これにより、ESP は aud クレーム内で、指定されたクライアント ID のいずれかを持つ JWT を受け入れます。
[[["わかりやすい","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 UTC。"],[[["\u003cp\u003eThe Extensible Service Proxy (ESP) validates JSON Web Tokens (JWTs) sent in the authorization header of HTTP requests, eliminating the need for custom authentication code in your API.\u003c/p\u003e\n"],["\u003cp\u003eTo configure ESP for client authentication, you must define a security requirement object and a security definitions object in your OpenAPI document, including details like the issuer and the public key location.\u003c/p\u003e\n"],["\u003cp\u003eESP efficiently validates JWTs by caching the issuer's public keys and validated JWTs, improving performance.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003ex-google-audiences\u003c/code\u003e field in your OpenAPI document can be used to specify allowed client IDs, extending access beyond the backend service name.\u003c/p\u003e\n"],["\u003cp\u003eWhile the \u003ccode\u003eAuthorization: Bearer\u003c/code\u003e header is the recommended way to send an authentication token, you can also use a query parameter called \u003ccode\u003eaccess_token\u003c/code\u003e.\u003c/p\u003e\n"]]],[],null,["# Using a custom method to authenticate users\n\nOpenAPI \\| gRPC\n\n\u003cbr /\u003e\n\nThis page describes how to support user authentication in Cloud Endpoints.\n\nTo authenticate a user, a client application must send a\n[JSON Web Token (JWT)](https://jwt.io/) in the authorization header of the\nHTTP request to your backend API. The\n[Extensible Service Proxy (ESP)](/endpoints/docs/glossary#extensible_service_proxy)\nvalidates the token on behalf of your API, so you don't have to add any code in\nyour API to process the authentication. However, you do need to configure your\nOpenAPI document to support your chosen authentication methods.\n\nESP validates a JWT in a performant way by using the JWT's\nissuer's public keys. ESP caches the public keys for five\nminutes. In addition, ESP caches validated JWTs for five minutes\nor until JWT expiry, whichever happens first.\n\nBefore you begin\n----------------\n\n- Add authentication code to your client application, following the authentication provider's documentation.\n\n\n- When your client application sends an HTTP request, the authorization header in the request must contain the following JWT claims:\n - `iss` (issuer)\n - `sub` (subject)\n - `aud` (audience)\n - `iat` (issued at)\n - `exp` (expiration time)\n\n\u003cbr /\u003e\n\nConfiguring ESP to support client authentication\n------------------------------------------------\n\n\nYou must have a [security\nrequirement object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#securityRequirementObject) and a [security\ndefinitions object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#securityDefinitionsObject) in your OpenAPI document for ESP to\nvalidate the claims in the signed JWT.\n\n\u003cbr /\u003e\n\nTo support custom authentication:\n\n1. Add the following to the security definition in your OpenAPI\n document:\n\n securityDefinitions:\n your_custom_auth_id:\n authorizationUrl: \"\"\n flow: \"implicit\"\n type: \"oauth2\"\n # The value below should be unique\n x-google-issuer: \"issuer of the token\"\n x-google-jwks_uri: \"url to the public key\"\n # Optional. Replace YOUR-CLIENT-ID with your client ID\n x-google-audiences: \"YOUR-CLIENT-ID\"\n\n2. Add a security section at either the API level to apply to the entire\n API, or at the method level to apply to a specific method.\n\n security:\n - your_custom_auth_id: []\n\n\nYou can define multiple security definitions in the OpenAPI document, but each\ndefinition must have a different issuer. If you use security sections at both\nthe API level and at the method level, the method-level settings override the\nAPI-level settings.\n\n\u003cbr /\u003e\n\n\nThe `x-google-audiences` field isn't required. ESP\naccepts all JWTs with the backend service name in the form of\n`https://`\u003cvar translate=\"no\"\u003eSERVICE_NAME\u003c/var\u003e in the `aud` claim. To\nallow additional client IDs to access the backend service, you can specify the\nallowed client IDs in the `x-google-audiences` field by using\ncomma-separated values. ESP then accepts the JWTs with any of the\nspecified client IDs in the `aud` claim.\n\n\u003cbr /\u003e\n\n\nESP supports two asymmetric public key formats defined\nby the `x-google-jwks_uri` OpenAPI extension:\n\n- [JWK set format](https://tools.ietf.org/html/rfc7517#section-5). For example: \n\n ```\n x-google-jwks_uri: \"https://YOUR_ACCOUNT_NAME.YOUR_AUTH_PROVIDER_URL/.well-known/jwks.json\"\n ```\n- [X509](https://tools.ietf.org/html/rfc5280). For example: \n\n ```\n x-google-jwks_uri: \"https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com\"\n ```\n\n\u003cbr /\u003e\n\n\nIf you are using a symmetric key format, set `x-google-jwks_uri` to\nthe URI of a file that contains the base64url-encoded key string.\n\n\nIf you omit `x-google-jwks_uri`, ESP will follow the\n[OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig)\nprotocol to automatically discover the JWKS URI for the given OpenID provider.\nESP will make a request to \u003cvar translate=\"no\"\u003ex-google-issuer\u003c/var\u003e`/.well-known/openid-configuration`,\nparse the JSON response, and read the JWKS URI from the top-level `jwks_uri` field.\n\n\nNote that omitting `x-google-jwks_uri` will result in higher cold start times, as\nESP has to make an extra remote call on startup.\nTherefore, it is only recommended to omit this field if the JWKS URI changes often.\nMost certified OpenID providers (such as Google, Auth0, and Okta) have stable JWKS URIs.\n\n\u003cbr /\u003e\n\n\nYou may also customize JWT locations by adding `x-google-extensions`. For details, see [openAPI extensions](/endpoints/docs/openapi/openapi-extensions#x-google-jwt-locations).\n\n\u003cbr /\u003e\n\nMaking an authenticated call to an Endpoints API\n------------------------------------------------\n\nWhen you send a request using an authentication token, for security reasons, we\nrecommend that you put the token in the `Authorization:Bearer` header. For\nexample: \n\n curl -H \"Authorization: Bearer ${TOKEN}\" \"${ENDPOINTS_HOST}/echo\"\n\nHere, `ENDPOINTS_HOST` and `TOKEN` are environment variables containing your\nAPI host name and authentication token, respectively. See\n[Making an authenticated request to an Endpoints API](/endpoints/docs/openapi/service-account-authentication#making_an_authenticated_request).\nfor sample code that sends a request using the `Authorization:Bearer` header.\n\nIf you cannot use the header when sending the request, you can put the\nauthentication token in a query parameter called `access_token`. For example: \n\n curl \"${ENDPOINTS_HOST}/echo?access_token=${TOKEN}\"\n\nReceiving authenticated results in your API\n-------------------------------------------\n\n\nESP usually forwards all headers it receives. However, it overrides the\noriginal `Authorization` header when the backend address is specified by\n`x-google-backend` in OpenAPI specification or `BackendRule`\nin gRPC service configuration.\n\n\nESP will send the authentication result in the `X-Endpoint-API-UserInfo`\nto the backend API. We recommend using this header instead of the original\n`Authorization` header. This header is a string that `base64url` encodes\na JSON object. The JSON object format differs between ESPv2 and ESP.\nFor ESPv2, the JSON object is exactly the original JWT payload. For ESP,\nthe JSON object uses different field names and put original JWT payload under `claims` field.\nSee [Handle JWTs in the backend service](/endpoints/docs/openapi/migrate-to-esp-v2#handle-jwt)\nfor more information on the format.\n\n\u003cbr /\u003e\n\nWhat's next\n-----------\n\n\n- [Troubleshooting JWT validation](/endpoints/docs/openapi/troubleshoot-jwt)\n- [Authentication between services](/endpoints/docs/openapi/service-account-authentication)\n\n\u003cbr /\u003e"]]