This document and the Token types document cover the multiple tokens used by Google Cloud for authentication and authorization. They're intended for people who want to learn how token-based authentication works, or who want to implement authentication without using the Cloud Client Libraries.
You don't need to know this information when you interact with Google Cloud APIs using the Cloud Client Libraries, the Google Cloud console, or the Google Cloud CLI—the process of selecting the right type of token, and obtaining and refreshing those tokens is handled automatically for you.
User authentication
When human users interact with Google Cloud, they don't interact with
Google Cloud APIs directly. Instead, they use a client to act on their behalf.
The client that they use might be a web application, a desktop application, or a
utility like the Google Cloud CLI or curl.
Because the client makes requests and not the user, Google Cloud can't request identity information from the user directly to check if they have permission to use an API. Instead, this identity is passed to the API through the client in the form of a token, which is included in each API request.
A user authentication token encodes the following information:
The identity of the user.
The identity of the client.
Assurance that the client is allowed to act on behalf of the user.
Authenticating the user and authorizing the client involves the following parties:
A user.
A client that acts on behalf of the user.
An authorization server, which Google APIs rely on to authenticate the client.
A Google Cloud API that the client interacts with.
Clients can't issue tokens themselves. Instead, they must work with an authorization server to do the following:
Authenticate the user.
Authenticate the client.
Authorize the client to act on the user's behalf.
Issue a token to the client.
A user who authenticates by signing in to their Google Account is a user principal. The principal has a principal identifier similar to the following:
user:alex@example.com
A user who authenticates using workforce identity federation and an external identity provider is a workforce identity pool principal. The principal has a principal identifier similar to the following:
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/raha@altostrat.com
Workload authentication
Some clients need to interact with Google APIs on their own behalf. For example, a scheduled job might need to read data from BigQuery or Cloud Storage without any human user being involved.
Clients that act unattended and on their own behalf are referred to as workloads. Unlike user authentication, workload authentication combines authenticating the user and authorizing the client into a single step. Because of this, a workload authentication token encodes the identity of only the client.
Workload authentication and authorization involves the following parties:
A workload, acting as both a client and a user, and on its own behalf.
An authorization server, which Google APIs rely on to authenticate the client.
A Google Cloud API that the client interacts with.
To access Google Cloud APIs, clients must work with an authorization server to do the following:
Authenticate the client.
Authorize the client.
Issue a token to the client.
An authenticated workload is also referred to as a principal, but workloads use different principal identifiers than users.
A workload that authenticates using a service account is a service account principal. The principal has a principal identifier similar to the following:
serviceAccount:my-service-account@my-project.iam.gserviceaccount.com
A workload that authenticates using workload identity federation is a workload identity pool principal. The principal has a principal identifier similar to the following:
principal://iam.googleapis.com/projects/PROJECT_NAME/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Authorization servers
Google Cloud shares specific authentication and authorization facilities with other Google services. Shared facilities include Sign in with Google, and the OpenID Connect and OAuth 2.0 services provided by Google Identity.
Other authentication-related services, such as Workload Identity Federation and Workforce Identity Federation, are specific to Google Cloud and can't be used for other Google services.
Because of this split, Google Cloud uses two authorization servers. One is shared with other Google services, and the other is specific to Google Cloud. The following table describes the different servers and their properties.
| Authorization server | Authentication type | Authentication APIs | Principals |
|---|---|---|---|
| Google authorization server |
|
|
|
| Google Cloud Identity and Access Management (IAM) authorization server |
|
The authorization servers are global services and can be accessed from any Google Cloud region. However, not all regions contain deployments of both authorization servers:
The Google authorization server is available in select regions.
The Google Cloud IAM authorization server is available in all regions.
To optimize reliability, use the Google Cloud IAM authorization server whenever possible.
What's next
Read about token types.