This document and the Token types document cover the multiple tokens used by Trusted Cloud by S3NS 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 Trusted Cloud by S3NS APIs using the Cloud Client Libraries, the Trusted 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 Trusted Cloud by S3NS, they don't interact with
Trusted Cloud by S3NS 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, Trusted Cloud by S3NS 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 Trusted Cloud by S3NS 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 Trusted Cloud by S3NS API that the client interacts with.
To access Trusted Cloud by S3NS 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.s3ns-system.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
Trusted Cloud by S3NS 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 Trusted Cloud by S3NS and can't be used for other Google services.
Because of this split, Trusted Cloud by S3NS uses two authorization servers. One is shared with other Google services, and the other is specific to Trusted Cloud by S3NS. The following table describes the different servers and their properties.
| Authorization server | Authentication type | Authentication APIs | Principals |
|---|---|---|---|
| Google authorization server |
|
|
|
| Trusted Cloud by S3NS Identity and Access Management (IAM) authorization server |
|
The authorization servers are global services and can be accessed from any Trusted Cloud by S3NS region. However, not all regions contain deployments of both authorization servers:
The Google authorization server is available in select regions.
The Trusted Cloud by S3NS IAM authorization server is available in all regions.
To optimize reliability, use the Trusted Cloud by S3NS IAM authorization server whenever possible.
What's next
Read about token types.