Choosing an Authentication Method

Google Cloud Endpoints supports multiple authentication methods that are suited to different applications and use cases. This document provides an overview and sample use cases for each supported authentication method.

API keys

API keys do not require client libraries and are transparent to the user. They identify the project by having a strong association between a key and a project. A developer generates an API key in a project in the Google Cloud Platform console and embeds that key in every call to the API.

Unlike credentials that use short-live tokens or signed requests, API keys are a part of the request and are therefore considered to be vulnerable to man in the middle attacks and therefore less secure.

API keys do not require a client library, they can be easily added to any HTTP call as a query parameter or in the header.

The Extensible Service Proxy will use Google Service Control API to validate an API key and its association with a project's enabled API.

Use case

API keys should be used when API calls do not involve user data. This means the data returned for a request is the same regardless of the caller. APIs such as the Google Maps API and the Google Translation API use API keys.

Firebase authentication

Firebase Authentication provides backend services, app SDKs, and libraries to authenticate users to a mobile or web app. It authenticates users using a variety of credentials such as Google, Facebook, Twitter, or GitHub.

The Firebase client library signs a JSON Web Token (JWT) with a private key after the user has successfully signed in. The Extensible Service Proxy will validate the JWT was signed by Firebase and that the x-google-issuer matches the setting in API configuration.

Use case

Firebase should be used when the API calls involve any user data and the API is intended to be used in flows where the user has an user interface for example, from mobile and web apps.

For APIs that are not used with an user interface, we recommend using Google Auth and Service Accounts.

Auth0 authentication

Auth0 authenticates and authorizes apps and APIs and is identity, stack, and device agnostic.

Auth0 supports a large number of providers and the Security Assertion Markup Language specification. It provides backend services, SDKs and user interface libraries for authenticating users in web and mobile apps.

The client library provided by Auth0 generates and signs a JWT once the user has signed in. The Extensible Service Proxy validates the JWT was signed by Auth0 and the x-google-issuer matches what is set in the API configuration.

Use case

Auth0 is well suited for consumer and enterprise web and mobile apps.

Google authentication

Google authentication allows users to authenticate by signing in with a Google account. Once authenticated, the user has access to all Google services.

A Google ID token, which is a JWT signed by Google, can be used to make calls to Google APIs and Cloud Endpoints APIs.

The Extensible Service Proxy will check that the JWT was signed by Google and https://accounts.google.com is listed as an x-google-issuer in the API configuration.

Use case

Google authentication is favourable when all users have Google accounts. You may choose to use Google authentication, for example, if your API accompanies Google Apps (for example, a Google Drive companion).

Google Auth and Service Accounts

You can generate and sign a JWT using a Service Account and Google-provided client libraries for a particular Google Cloud Platform project. A JWT representing a service account can be signed either by Google or by the service account.

The Extensible Service Proxy will validate a Google-signed JWT using the public key and ensure that Google is listed as the x-google-issuer in the API configuration. For JWTs signed by the service account, the Service Proxy will validate it using the service account’s public key and ensure that the service account is specified in the API configuration.

Google ID tokens are recommended for service accounts because the API producer only needs to whitelist Google as an x-google-issuer for all service accounts.

Use case

Google authentication and service accounts are well suited for microservices.

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Cloud Endpoints with gRPC