Using API Keys

This guide shows how to create API keys, and how to set up
API key restrictions, for GCP applications. To learn more about authenticating
to a GCP API, see Authentication overview. For
information about setting up API keys for Google Maps, see the
Google Maps documentation.

Note: Do not use API keys for local or production applications, except in the
specific cases described below. For almost all cases, you should use
service accounts.

API keys are a simple encrypted string
that can be used when calling certain APIs that don't need to access private
user data. API keys are useful in clients such as browser and mobile
applications that don't have a backend server. The API key is used to track API
requests associated with your project for quota and billing.

API keys do not identify the user or the application making the API request,
so you can't restrict access to specific users or service accounts.

It is easier for others to discover and use your API key.

Because of this we recommend using the standard authentication flow instead. However, there are limited
cases where API keys are more appropriate. For example, if you're developing a
mobile application that needs to use the Google Cloud Translation API, but
doesn't otherwise need a backend server, API keys are the simplest way to
authenticate to that API. In most cases, we recommend having your application
communicate to a backend server that handles authenticating to, and calling,
Google Cloud Platform services.

Creating an API key

To create an API key, your account must be granted the primitive Editor role
(roles/editor) on the current project. For more information, see
primitive roles.

Securing an API key

When you use API keys in your applications, take care to keep them secure.
Publicly exposing your credentials can result in your account being compromised,
which could lead to unexpected charges on your account. To help keep your API
keys secure, follow these best practices:

Do not embed API keys directly in code. API keys that are embedded in code
can be accidentally exposed to the public. For example, you may forget to remove
the keys from code that you share. Instead of embedding your API keys in your
applications, store them in environment variables or in files outside of your
application's source tree.

Do not store API keys in files inside your application's source tree. If you
store API keys in files, keep the files outside your application's source tree
to help ensure your keys do not end up in your source code control system.
This is particularly important if you use a public source code management
system such as GitHub.

Regenerate your API keys periodically. You can regenerate API keys from the
Credentials page by
clicking Regenerate key for each key. Then, update your applications to use
the newly-generated keys. Your old keys will continue to work for 24 hours
after you generate replacement keys.

Review your code before publicly releasing it. Ensure that your code does not
contain API keys or any other private information before you make your code
publicly available.

Adding restrictions to API keys

An API key is unrestricted by default. Unrestricted keys are insecure because
they can be viewed publicly, such as from within a browser, or they can be
accessed on a device where the key resides.

For production applications, set both application and API restrictions.

Select the name of an existing API key. The restrictions section appears at
the bottom of the page.

Application restrictions

Application restrictions specify which web sites, IP addresses, or apps can use
an API key. Add application restrictions based on your application type. You
can only set one restriction type per API key.

Select the Application restrictions tab in the Key restrictions
section.

Choose the restriction type based on your application needs. To add more
than one value for any restriction, type the first value, and then press the
Enter key. Repeat to add values.

Use None for testing purposes only.

Use HTTP referrers for API clients that run on a web
browser, so that only the specified pages can call the API. These types of
applications expose their API keys publicly, so we recommend
using a service account instead.
See Adding HTTP restrictions
for examples.