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 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.
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 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
the setting in API configuration.
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 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.
Auth0 is well suited for consumer and enterprise web and mobile apps.
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
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.
Google authentication and service accounts are well suited for microservices.