Authentication at Google

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

This document helps you understand some key authentication concepts, and where to get help with implementing or troubleshooting authentication. The primary focus of the authentication documentation is for Google Cloud services, but the list of authentication use cases and the introductory material on this page includes use cases for other Google products as well.

Introduction

Authentication is the process by which your identity is confirmed through the use of some kind of credential. Authentication is about proving that you are who you say you are.

Google provides many APIs and services, which require authentication to access. Google also provides a number of services that host applications written by our customers; these applications also need to determine the identity of their users.

I want to... Information
Authenticate to a Google Cloud service from my application using a high-level programming language. Set up Application Default Credentials, and then use one of the Cloud Client Libraries.
Authenticate to an application that is running on Cloud Run or Cloud Functions. Get an OpenID Connect (OIDC) ID token and provide it with your request.
Implement user authentication for an application that accesses Google or Google Cloud services and resources. See Authenticate application users for a comparison of options.
Try out some gcloud commands or Google Cloud REST API calls in my local development environment. Set up Application Default Credentials with your login credentials. You can then use a command-line tool such as curl to call the REST API.
Get help with another authentication use case. See the Authentication use cases page.
See a list of the products Google provides in the identity and access management space. See the Google identity and access management products page.

Types of authentication

Authentication is required to access most resources and applications. This documentation supports technical practitioners creating application code with one of the following goals:

OAuth 2.0

Google APIs implement and extend the OAuth 2.0 framework. The OAuth 2.0 framework outlines various authentication "flows" or authentication approaches. Generally, the application presents credentials, which represent a principal (either a user or a service account), to an intermediate module called an Authorization Server. The Authorization Server responds with a token, which the application can use to authenticate with the service and access resources. The token includes one or more scopes, which reflect what access the application is authorized to make. The application then presents the token to the resource server to gain access to the resources.

Authorization for Google Cloud services

Google Cloud services use Identity and Access Management (IAM) for authentication. IAM offers granular control, by principal and by resource. When you authenticate to Google Cloud services, you generally use a scope that includes all Google Cloud services (https://www.googleapis.com/auth/cloud-platform).

OAuth 2.0 scopes can provide a second layer of protection, which is useful if your code is running in an environment where token security is a concern, such as a mobile app. In this scenario, you can use finer-grained scopes to reduce risk in the event of a compromised token. OAuth 2.0 scopes are also used to authorize access to user data.

Application Default Credentials (ADC)

ADC is a strategy used by Cloud Client Libraries and Google API Client Libraries to automatically find credentials based on the application environment, and use those credentials to authenticate to Google Cloud APIs. When you set up ADC and use a client library, your code can run in either a development or production environment without changing how your application authenticates to Google Cloud services and APIs.

If you are writing code that needs to use Google Cloud services, you should use ADC whenever possible. Using ADC can simplify your development process, because it lets you use the same authentication code in a variety of environments.

You configure ADC by providing your credentials, based on where you want your code to run. After you provide your credentials to ADC, ADC automatically locates credentials and gets a token in the background, enabling your authentication code to run in different environments without modification. For example, the same version of your code could authenticate with Google Cloud APIs when running on a development workstation or on Compute Engine.

Terminology

The following terms are important to understand when discussing authentication and authorization.

Authentication

Authentication is the process of determining the identity of the principal attempting to access a resource.

Authorization

Authorization is the process of determining whether the principal or application attempting to access a resource has been authorized for that level of access.

Credentials

For authentication, credentials are a digital object that provide proof of identity. Passwords, PINs, and biometric data can all be used as credentials, depending on the application requirements. For example, when you log into your Google Account, you provide your password and satisfy any two-factor authentication requirement as proof that the account in fact belongs to you, and you are not being spoofed by a bad actor.

Tokens are sometimes referred to as credentials, but for this documentation, they are instead referred to as a digital object that proves that the caller provided proper credentials, but they are not credentials themselves.

The type of credential you need to provide depends on what you are authenticating to. The following types of credentials can be created in the Google Cloud console:

  • API keys

    Unlike other credentials, API keys do not identify a principal. API keys provide a Google Cloud project for billing and quota purposes.

    Many Google APIs do not accept API keys. For more information about API keys, see API keys.

  • OAuth Client IDs

    OAuth Client IDs are used to identify an application to Google. This is necessary when you want to access resources owned by your end users, also called three-legged OAuth (3LO). For more information about how to get and use an OAuth Client ID, see Setting up OAuth 2.0.

Principal

A principal is an identity that can be granted access to a resource. For authentication, Google APIs support two types of principals: user accounts and service accounts.

Whether you use a user account or a service account to authenticate depends on your use case. You might use both, each at different stages of your project or in different development environments.

User accounts

User accounts represent a developer, administrator, or any other person who interacts with Google APIs and services.

User accounts are managed as Google Accounts, either with Google Workspace or Cloud Identity. They can also be user accounts that are managed by a third-party identity provider and federated with workforce identity federation.

With a user account, you can authenticate to Google APIs and services in the following ways:

Service accounts

Service accounts are accounts that do not represent a human user. They provide a way to manage authentication and authorization when a human is not directly involved, such as when an application needs to access Google Cloud resources. Service accounts are managed by IAM.

The following list provides some methods for using a service account to authenticate to Google APIs and services, in order from most secure to least secure.

Token

For authentication and authorization, a token is a digital object that shows that a caller provided proper credentials that were exchanged for that token. The token contains information about the identity of the principal making the request and what kind of access they are authorized to make.

Tokens can be thought of as being like hotel keys. When you check in to a hotel and present the proper documentation to the hotel registration desk, you receive a key that gives you access to specific hotel resources. For example, the key might give you access to your room and the guest elevator, but would not give you access to any other room or the service elevator.

With the exception of API keys, Google APIs do not support credentials directly. Your application must acquire or generate a token and provide it to the API. There are several different types of tokens. For more information, see Token types.

Workload and workforce

Google Cloud identity and access products enable access to Google services and resources for both programmatic access and human users. Google uses the terms workload for programmatic access and workforce for user access.

Workload identity federation lets you provide access to workloads running outside of Google without having to create and manage service account keys.

Workforce identity federation lets you use an external identity provider to authenticate and authorize a workforce—a group of users, such as employees, partners, and contractors—using IAM, so that the users can access Google Cloud services.

What's next