Cloud Endpoints
Endpoints is an API management system that helps you secure, monitor, analyze, and set quotas on your APIs using the same infrastructure Google uses for its own APIs. After you deploy your API to Endpoints, you can use the Cloud Endpoints Portal(https://cloud.google.com/endpoints/docs/dev-portal-overview) to create a developer portal, a website that users of your API can access to view documentation and interact with your API.
Cloud Endpoints for OpenAPI
Cloud Endpoints is an API management system that helps you secure, monitor, analyze, and set quotas on your APIs using the same infrastructure Google uses for its own APIs. Endpoints works with the Extensible Service Proxy (ESP) (https://cloud.google.com/endpoints/docs/openapi/glossary#extensible_service_proxy) and the Extensible Service Proxy V2 (ESPv2) (https://cloud.google.com/endpoints/docs/openapi/glossary#extensible_service_proxy_v2) to provide API management. You can find out more about Endpoints, ESP, and ESPv2 in About Endpoints.
OpenAPI overview
Cloud Endpoints supports APIs that are described using version 2.0 of the OpenAPI specification. Your API can be implemented using any publicly available REST framework such as Django or Jersey. You describe your API in a JSON or YAML file referred to as an OpenAPI document. This page describes some of the benefits to using OpenAPI, shows a basic OpenAPI document, and provides additional information to help you get started with OpenAPI.
Choosing an Authentication Method
Cloud Endpoints supports multiple authentication methods that are suited to different applications and use cases. The Extensible Service Proxy (ESP) uses the authentication method that you specify in your service configuration to validate incoming requests before passing them to your API backend. This document provides an overview and sample use cases for each supported authentication method.
1. API keys
An API key is a simple encrypted string that identifies a Google Cloud project for quota, billing, and monitoring purposes. A developer generates an API key in a project in the Cloud Console and embeds that key in every call to your API as a query parameter.
If you specify an API key requirement in your service configuration, ESP uses the API key to look up the Google Cloud project that the API key is associated with. ESP rejects requests unless the API key was generated in your Google Cloud project or within other Google Cloud projects in which your API has been enabled. For more information, see Restricting API access with API keys
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. You can use API keys in addition to one of the authentication methods described below. For security reasons, don’t use API keys by themselves when API calls contain user data.
Use case
If you want to use Endpoints features such as quotas, each request must pass in an API key so that Endpoints can identify the Google Cloud project that the client application is associated with.
For more information about API keys, see Why and when to use API keys.
2.Firebase authentication
Firebase authentication provides backend services, SDKs, and libraries to authenticate users to a mobile or web app. It authenticates users by 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 successfully signs in. ESP validates that the JWT was signed by Firebase and that the iss (issuer) claim in the JWT, which identifies your Firebase application, matches the x-google-issuer setting in the service configuration.
Use case
We recommend using Firebase when the API calls involve any user data and the API is intended to be used in flows where the user has a user interface for example, from mobile and web apps. For more information, see Using Firebase to authenticate users.
3. Auth0
Auth0 authenticates and authorizes applications and APIs regardless of identity provider, platform, stack and device.
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. Auth0 integrates with several third-party identity providers and also provides custom user account management.
The client library provided by Auth0 generates and signs a JWT once the user signs in. ESP validates the JWT was signed by Auth0 and that the iss claim in the JWT, which identifies your Auth0 application, matches the x-google-issuer setting in the service configuration.
Use case
Auth0 is suited for consumer and enterprise web and mobile apps. For more information, see the Auth0 tab in For more information, see Using Auth0 to authenticate users.
4. Google ID token authentication
Authentication with a Google ID token allows users to authenticate by signing in with a Google account. Once authenticated, the user has access to all Google services. You can use Google ID tokens to make calls to Google APIs and to APIs managed by Endpoints. ESP validates the Google ID token by using the public key and ensures that the iss claim in the JWT is https://accounts.google.com.
Use case
Authentication with a Google ID token is recommended when all users have Google accounts. You might choose to use Google ID token authentication, for example, if your API accompanies a Google application, such as Google Drive companion. Google ID token authentication allows users to authenticate by signing in with a Google account. Once authenticated, the user has access to all Google services. For more information see Using Google ID tokens to authenticate users.
5.Service accounts
To identify a service that sends requests to your API, you use a service account. The calling service uses the service account’s private key to sign a secure JSON Web Token (JWT) and sends the signed JWT in the request to your API.
Use case
JWTs and service accounts are well suited for microservices. For more information, see Authentication between services.
6.Custom authentication
You can use other authentication platforms to authenticate users as long as it conforms to the JSON Web Token RFC 7519.
Why and when to use API keys
This page provides background information on API keys and authentication: how each of these are used, the differences between them, and the scenarios where you should consider using API keys.
API keys are for projects, authentication is for users
Cloud Endpoints handles both API keys and authentication schemes, such as Firebase or Auth0. The main distinction between these two is:
API keys identify the calling project — the application or site — making the call to an API.
Authentication tokens identify a user — the person — that is using the app or site.
API keys provide project authorization
To decide which scheme is most appropriate, it’s important to understand what API keys and authentication can provide.
API keys provide
Project identification — Identify the application or the project that’s making a call to this API
Project authorization — Check whether the calling application has been granted access to call the API and has enabled the API in their project
API keys aren’t as secure as authentication tokens (see Security of API keys), but they identify the application or project that’s calling an API. They are generated on the project making the call, and you can restrict their use to an environment such as an IP address range, or an Android or iOS app.
By identifying the calling project, you can use API keys to associate usage information with that project. API keys allow the Extensible Service Proxy (ESP) to reject calls from projects that haven’t been granted access or enabled in the API.
Authentication of users
By contrast, authentication schemes typically serve two purposes:
User authentication — Securely verify that the calling user is who they claim to be.
User authorization — Check whether the user should have access to make this request.
Authentication schemes provide a secure way of identifying the calling user. Endpoints also checks the authentication token to verify that it has permission to call an API. Based on that authentication, the API server decides on authorizing a request.
If you need the ability to identify the user making the call, see Authenticating users.
While API keys identify the calling project, they don’t identify the calling user. For instance, if you have created an application that is calling an API, an API key can identify the application that is making the call, but not the identity of the person who is using the application.
If you need a more secure way to limit which projects or services can call your API, see Authentication between services.
Security of API keys
API keys are generally not considered secure; they are typically accessible to clients, making it easy for someone to steal an API key. Once the key is stolen, it has no expiration, so it may be used indefinitely, unless the project owner revokes or regenerates the key. While the restrictions you can set on an API key mitigate this, there are better approaches for authorization.
For examples, see Authenticating users.
When to use API keys
An API may restrict some or all of its methods to require API keys. It makes sense to do this if:
You do want to block anonymous traffic. API keys identify an application’s traffic for the API producer, in case the application developer needs to work with the API producer to debug an issue or show their application’s usage.
You want to control the number of calls made to your API.
You want to identify usage patterns in your API’s traffic. You can see application usage in APIs & services.
You want to filter logs by API key.
API keys cannot be used for:
Identifying individual users — API keys don’t identify users, they identify projects.
Secure authorization.
Identifying the creators of a project.
Service Infrastructure doesn’t provide a method to directly look up projects from API keys.
How to use API keys
Authentication between services
Using Firebase to authenticate users
Creating and managing projects
Resource hierarchy
Understanding API keys
An application programming interface key (API key) is a unique code that is passed in to an API to identify the calling application or user. API keys are used to track and control how the API is being used, for example to prevent malicious use or abuse of the API. The API key often acts as both a unique identifier and a secret token for authentication, and is assigned a set of access that is specific to the identity that is associated with it.
What are API Keys? | Using API Keys
Google Oauth in React Js | Google Authentication Example | React-Google-Login
How to save refresh token and get a new UserCredential and access token using refresh token
G Suite OAuth Token Audit (Google Apps Script)
G Suite & Okta – Google Integration
POSTMAN AUTHORIZATION | BASIC AUTH & AUTH 2.0 | GENERATE ACCESS TOKEN