A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://cloud.google.com/endpoints/docs/openapi/authenticating-users-firebase below:

Using Firebase to authenticate users | Cloud Endpoints with OpenAPI

Using Firebase to authenticate users

Stay organized with collections Save and categorize content based on your preferences.

This page describes how to support user authentication in Cloud Endpoints.

To authenticate a user, a client application must send a JSON Web Token (JWT) in the authorization header of the HTTP request to your backend API. The Extensible Service Proxy (ESP) validates the token on behalf of your API, so you don't have to add any code in your API to process the authentication. However, you do need to configure your OpenAPI document to support your chosen authentication methods.

ESP validates a JWT in a performant way by using the JWT's issuer's public keys. ESP caches the public keys for five minutes. In addition, ESP caches validated JWTs for five minutes or until JWT expiry, whichever happens first.

Before you begin Configuring your OpenAPI document

You must have a security requirement object and a security definitions object in your OpenAPI document for ESP to validate the claims in the signed JWT.

To support Firebase authentication:

  1. Add the following to the security definition in your OpenAPI document:

      securityDefinitions:
        firebase:
          authorizationUrl: ""
          flow: "implicit"
          type: "oauth2"
          # Replace YOUR-PROJECT-ID with your project ID
          x-google-issuer: "https://securetoken.google.com/YOUR-PROJECT-ID"
          x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com"
          x-google-audiences: "YOUR-PROJECT-ID"
    
    Note: When defining security schemes in your OpenAPI document for JWT authentication, you must include the authorizationUrl field, even if its value is an empty string (""). This is a requirement of the OpenAPI specification. Although the field is mandatory for the spec, its value is not used by Cloud Endpoints or API Gateway when validating a JWT.
  2. Add a security section at either the API level to apply to the entire API, or at the method level to apply to a specific method.

      security:
        - firebase: []
    

You can define multiple security definitions in the OpenAPI document, but each definition must have a different issuer. If you use security sections at both the API level and at the method level, the method-level settings override the API-level settings.

You may also customize JWT locations by adding x-google-extensions. For details, see openAPI extensions.

Making an authenticated call to an Endpoints API

When you send a request using an authentication token, for security reasons, we recommend that you put the token in the Authorization:Bearer header. For example:

curl -H "Authorization: Bearer ${TOKEN}" "${ENDPOINTS_HOST}/echo"

Here, ENDPOINTS_HOST and TOKEN are environment variables containing your API host name and authentication token, respectively. See Making an authenticated request to an Endpoints API. for sample code that sends a request using the Authorization:Bearer header.

If you cannot use the header when sending the request, you can put the authentication token in a query parameter called access_token. For example:

curl "${ENDPOINTS_HOST}/echo?access_token=${TOKEN}"
Receiving authenticated results in your API

ESP usually forwards all headers it receives. However, it overrides the original Authorization header when the backend address is specified by x-google-backend in OpenAPI specification or BackendRule in gRPC service configuration.

ESP will send the authentication result in the X-Endpoint-API-UserInfo to the backend API. We recommend using this header instead of the original Authorization header. This header is a string that base64url encodes a JSON object. The JSON object format differs between ESPv2 and ESP. For ESPv2, the JSON object is exactly the original JWT payload. For ESP, the JSON object uses different field names and put original JWT payload under claims field. See Handle JWTs in the backend service for more information on the format.

What's next

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-13 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-13 UTC."],[[["Cloud Endpoints uses JSON Web Tokens (JWT) for user authentication, validated by the Extensible Service Proxy (ESP) without requiring additional code in your API."],["The client application must include specific JWT claims (iss, sub, aud, iat, exp) in the authorization header of HTTP requests for successful authentication."],["OpenAPI documents need security requirement and definition objects for ESP to validate JWT claims, such as using Firebase authentication with the necessary security settings and project ID."],["Authentication tokens can be sent in the `Authorization:Bearer` header, or alternatively as an `access_token` query parameter, for making calls to an Endpoints API."],["ESP forwards the authentication results to the backend API in the `X-Endpoint-API-UserInfo` header, which is a base64url-encoded JSON object containing the JWT payload and is the recommended way of accessing the authentication results."]]],[]]


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4