Short-Lived Credentials and Impersonation

Short-lived IAM credentials are temporary tokens issued for a privilege-bearing service account through the IAM Service Account Credentials API (opens in a new tab). A direct request always involves two identities: a caller that requests the credential and the privilege-bearing service account (PRIV_SA) for which the credential is created. The caller must hold an impersonation role on the privilege-bearing service account, and the resulting credential expires without a refresh token, so the caller must repeat the request after expiry. This pattern enables temporary privilege elevation without distributing long-lived service account keys (opens in a new tab).

The four main formats are OAuth 2.0 access tokens for Google APIs, OpenID Connect (OIDC) ID tokens for a specific service URL, self-signed JSON Web Tokens (JWTs) presented directly to selected APIs, and signed Cloud Storage URLs for object-level access. Each format differs in who issues it, how long it lives, and which destination accepts it. The secure delegation pattern is the same across types: dedicated single-purpose service accounts hold only needed resource roles, a broker holds a token-creator role, and the broker issues short-lived credentials to the component that needs them.

1.1OAuth 2.0 Access Tokens

An OAuth 2.0 access token is an opaque bearer token that authenticates a service account principal and authorizes calls to most Google APIs. The token flows from the caller to the IAM Service Account Credentials API for issuance and then from the caller to the target Google API for use. The token is restricted to specific OAuth scopes such as https://www.googleapis.com/auth/cloud-platform, can be inspected for diagnostics at https://oauth2.googleapis.com/tokeninfo, cannot be revoked, and remains valid until expiry.

Access tokens are created with the serviceAccounts.generateAccessToken method. The request posts to https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/PRIV_SA:generateAccessToken with a scope array and a lifetime such as 300s. For local development, the same result can be obtained with gcloud auth print-access-token --impersonate-service-account=PRIV_SA after signing in with the caller user account. The caller needs the Service Account Token Creator role on the privilege-bearing service account to perform this impersonation.

Service account access tokens have a lifetime of 5 minutes to 12 hours. The default maximum is 1 hour (3,600 seconds), and the maximum can be extended to 12 hours (43,200 seconds) only when the service account is added to an organization policy that includes the constraints/iam.allowServiceAccountCredentialLifetimeExtension list constraint. Choose access tokens when the workload needs to call Google Cloud APIs with the permissions of the service account for a bounded period.

1.2OpenID Connect ID Tokens

An OpenID Connect (OIDC) ID token is a JWT that proves the identity of a service account to a specific receiving service, rather than authorizing broad Google API access. The token carries an aud (audience) claim that names the target URI, such as a Cloud Run (opens in a new tab) service, Cloud Run function, or App Engine app, and the target service validates that the audience matches itself before accepting the call. Traffic therefore flows from the caller to the IAM Service Account Credentials API for issuance, then from the caller to the target service for authentication.

ID tokens are created with the serviceAccounts:generateIdToken method, which takes an audience and an optional includeEmail flag. The caller must have the iam.serviceAccounts.getOpenIdToken permission, granted through the Service Account OpenID Connect Identity Token Creator role (roles/iam.serviceAccountOpenIdTokenCreator) on the privilege-bearing service account. Other issuance paths produce the same token type without calling the API directly, including gcloud auth print-identity-token --audiences AUDIENCE, a direct request to the Compute Engine metadata server, and managed connectors that attach the token automatically.

Some Google Cloud connecting services can automatically include an ID token with the correct aud value when they invoke another service:

• Cloud Scheduler can include an ID token or access token when it invokes an HTTP target.
• Cloud Tasks can include an ID token or access token when it calls a service from an HTTP Target task.
• Pub/Sub can include an ID token with a message delivered to a push subscription.
• Workflows can include an ID token or access token when a workflow step invokes another service.

To generate an ID token by impersonating a service account, follow an ordered separation between the caller principal and the privilege-bearing service account:

1. Identify the privilege-bearing service account that will own the identity presented to the target.
2. Grant invoke roles to that service account on the target, such as Cloud Run Invoker (roles/run.invoker) or Cloud Functions Invoker (roles/cloudfunctions.invoker).
3. Establish the caller principal through Application Default Credentials (ADC), either as a user in development or as an attached service account on a Google Cloud resource.
4. Grant the caller the ID token creator role (roles/iam.serviceAccountOpenIdTokenCreator) on the privilege-bearing service account.
5. Request the token from the IAM Credentials API with the target audience, then present the returned ID token to the target service.

1.3Self-Signed JSON Web Tokens

A self-signed JSON Web Token (JWT) is a client-issued access credential in JWT format that authenticates a service account principal without a network call to Google's authorization server. The client signs the JWT itself with the service account key material and presents it directly as a bearer token, so issuance does not depend on the IAM Service Account Credentials API at request time. The JWT is constrained to an OAuth scope or to a specific API that accepts this format.

Self-signed JWTs are accepted by only some Google APIs, including examples such as the Cloud Healthcare API, which permits a signed JWT directly as a bearer token instead of an OAuth 2.0 access token. Their lifetime is 5 minutes to 1 hour, which is shorter than the maximum for IAM-issued service account access tokens. Choose a self-signed JWT when the target API documents support for it and avoiding the extra token-exchange round trip matters, otherwise use an IAM-issued access token for broad API compatibility.

1.4Signed Cloud Storage URLs and Downscoped Tokens

A signed Cloud Storage URL is a time-limited URL that grants temporary access to a specific Cloud Storage resource without requiring the requester to hold IAM permissions on the bucket or object. The URL embeds the authorization and expiry, so possession of the URL is sufficient to perform the permitted operation until it expires. Choose signed URLs when external users or applications need bounded, object-level download or upload access without becoming IAM principals.

Signed URLs differ from Credential Access Boundary tokens, which are another downscoping mechanism for Storage. A Credential Access Boundary token is an opaque access token issued by the IAM authorization server that is restricted to specific Cloud Storage objects, while a client-issued variant is issued by the client for a service account principal. Both mechanisms enforce least privilege by narrowing broad service account access to only the objects needed for the task, so compromise of one token does not expose the full privileges of the service account.

1.5Choosing the Credential Format

The credential-format decision compares issuer, lifetime, and the destination that accepts each credential. The issuer determines which service creates the credential, the lifetime determines how long leakage remains dangerous, and the destination determines whether scopes, audience, or object restrictions apply:

Because every credential expires quickly and carries only its audience, scope, or object restriction, compromise of one token does not expose long-lived key material. Create dedicated single-purpose service accounts, grant only needed resource roles to each privilege-bearing account, and let the broker issue the narrowest credential that still allows the task to complete.

Workload Identity Federation (opens in a new tab) is the Google Cloud mechanism for letting workloads running outside Google Cloud authenticate without downloadable service account keys. An external workload presents its native identity assertion to Google Cloud, exchanges that assertion for a short-lived federated token, and then uses that token to temporarily impersonate a Google Cloud service account. The trust boundary stays with the external identity provider, which continues to authenticate its own workloads, while Google Cloud trusts only specific assertions and issues credentials that expire automatically.

By contrast, a service account key authenticates as the service account until it is explicitly deleted, and its holder is responsible for private-key security, rotation, and validation. Federation therefore removes the long-lived secret that must be rotated, leaked, or stolen. There is no exported RSA private key to store, and every federated credential stops working after its short lifetime.

2.1Workload Identity Pools and Providers

A workload identity pool is the Google Cloud Identity and Access Management (IAM) resource that represents a trust boundary for external identities. A workload identity provider is the child resource inside the pool that describes one specific external identity source and how its assertions map to federated identities. The provider defines the audience that the external token must be issued for, using the format //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID/providers/PROVIDER_ID, where PROJECT_NUMBER is the Google Cloud project number, WORKLOAD_POOL_ID is the pool ID, and PROVIDER_ID is the provider ID.

Client libraries and the gcloud iam workload-identity-pools create-cred-config command use this audience value to bind a credential configuration to exactly one pool and provider. This binding enforces least privilege across hybrid and multi-cloud architectures because a credential configuration cannot be reused for a different pool or provider. Supported external sources include AWS, Azure, and OpenID Connect (OIDC) or Security Assertion Markup Language (SAML) providers.

2.2Token Exchange Flow for External Workloads

The federated authentication flow moves credentials from the external provider to Google Cloud APIs through an ordered exchange. The workload first obtains its native assertion from its own environment, then trades it for Google Cloud short-lived credentials that carry the service account identity:

1. Set up service account: Create and permission the IAM service account that the external workload will act as, so IAM allow policies grant only that service account access to target resources.
2. Configure pool and provider: Configure Workload Identity Federation for the external identity provider, which establishes the pool, provider, and attribute mapping that Google Cloud uses to trust incoming assertions.
3. Grant impersonation: Grant the federated identity permission to impersonate the service account, which creates the delegation from the pool identity to the service account.
4. Exchange and call: Exchange the external assertion at the Security Token Service (STS) for a federated token ($STS_TOKEN), then call generateAccessToken or generateIdToken on the IAM Credentials API with Authorization: Bearer $STS_TOKEN to obtain a short-lived Google Cloud token for the service account.

Traffic flows from the workload to the external provider for the subject token, then from the workload to STS for the federated token, then from the workload to the IAM Credentials API for the service account token, and finally from the workload to the destination Google Cloud API. For a Cloud Run service (opens in a new tab), the workload sends the resulting OIDC ID token in an Authorization: Bearer ID_TOKEN header or an X-Serverless-Authorization: Bearer ID_TOKEN header, where only the X-Serverless-Authorization header is checked if both are present.

2.3Short-Lived Token Types From Federation

Short-lived service account credentials from federation are OAuth 2.0 access tokens and OIDC ID tokens that expire about an hour after creation. The generation API and audience determine which destination accepts the token and which permissions it carries:

An OIDC ID token is a JSON Web Token (JWT) whose exp claim marks its expiration. Code that fetches tokens from the Compute metadata server always receives a valid token, while code that caches tokens must decode the JWT and refresh when exp approaches. This caching rule prevents a workload from presenting an expired identity proof to the destination service.

2.4Configurable Token Lifetime

Configurable token lifetime controls how long the impersonated service account access token remains valid when federation uses service account impersonation. The service-account-token-lifetime-seconds flag in gcloud iam workload-identity-pools create-cred-config sets the lifetime, with a default of one hour, a minimum of 600 seconds (10 minutes), and a maximum of 43200 seconds (12 hours). A lifetime greater than one hour depends on an Organization Policy Service exception that lists the service account as an allowed value under the constraints/iam.allowServiceAccountCredentialLifetimeExtension constraint.

Configuring a very short lifetime forces the client library to repeat the full exchange, including calls to the third-party token provider, each time the Google Cloud token expires even if the third-party token is still valid. Longer lifetimes reduce exchange traffic but extend the window in which a leaked token remains usable. Choose the shortest lifetime that still allows the workload to complete its work without excessive token refreshes.

2.5Managed Federation in Google Kubernetes Engine

Workload Identity Federation for Google Kubernetes Engine (GKE) is the managed form of the same pattern for pods running inside Google Cloud. When federation is enabled, GKE creates a fixed workload identity pool named PROJECT_ID.svc.id.goog, registers the cluster as an identity provider in that pool, and runs the GKE metadata server as a DaemonSet on every Linux node or native service on every Windows node. Each pod runs as a Kubernetes service account and obtains short-lived credentials through a Bound Service Account Token Volume, while each cluster acts as an OIDC provider whose issuer URI serves as the discovery endpoint for its JSON Web Key Set (JWKS).

The GKE metadata server (opens in a new tab) intercepts requests to http://metadata.google.internal (169.254.169.254:80) and returns tokens for the linked IAM service account, so traffic to the metadata server never leaves the hosting virtual machine instance. Enabling federation alone grants no IAM permissions; access still depends on IAM allow policies that bind the Kubernetes identity to roles on specific resources, optionally narrowed with conditions. This separation ensures that identity federation establishes who the pod is, while IAM allow policies control what that identity can do.

Service account impersonation is the process where a caller identity obtains short-lived credentials that carry the identity or permissions of a privilege-bearing service account. Token downscoping further restricts an OAuth 2.0 access token with Credential Access Boundaries so the token can access fewer resources than the service account itself can access. Together, impersonation and downscoping replace long-lived service account keys with temporary, least-privilege delegation for users and workloads.

Short-lived credentials are temporary tokens issued by the Service Account Credentials API (opens in a new tab) that expire after a short lifetime, by default after 1 hour, and access tokens issued through impersonation come without a refresh token. When the token expires, the caller must repeat the impersonation request to obtain a new token. This short lifetime creates less risk than user-managed service account keys because a leaked token stops working quickly and no long-lived private key is distributed.

3.1Service Account Impersonation Model

The direct impersonation model involves two identities that sit on opposite sides of a trust boundary. The caller identity, either a caller service account (CALLER_SA) or a caller user account (CALLER_ACCOUNT), sends a request to the Service Account Credentials API, and the privilege-bearing service account (PRIV_SA) is the identity whose permissions or identity the resulting token represents. The caller must hold an impersonation permission on PRIV_SA, while PRIV_SA must already hold Identity and Access Management (IAM) roles on the target resources, because impersonation never grants PRIV_SA new resource access.

The delegated request flow (opens in a new tab) extends direct impersonation when one call cannot supply all required permissions. In a delegation chain, the request flows from the original caller through one or more intermediate service accounts in order before the Service Account Credentials API generates a credential for the final PRIV_SA. Each service account in the chain must have the required impersonation permission on the next service account in the chain, and the resulting credential represents only the final service account, not the intermediates. Choose the direct method when one service account provides all needed permissions, and choose delegation only when architecture requires a series of token generation calls.

3.2IAM Roles and Permissions for Secure Impersonation

Roles for service account authentication (opens in a new tab) control whether a principal can attach, impersonate, or mint specific token types for a service account. The grant must be placed on PRIV_SA itself, so CALLER_SA depends on an allow-policy binding on PRIV_SA before the Service Account Credentials API will issue a token. Automated workloads such as applications on Compute Engine must authenticate as a service account caller, while local development and Google Cloud CLI (gcloud CLI) commands can authenticate as a user caller.

The Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) is the broad impersonation role for creating short-lived credentials for a service account. The role includes five permissions that each enable a different credential operation:

• iam.serviceAccounts.getAccessToken creates OAuth 2.0 access tokens
• iam.serviceAccounts.getOpenIdToken creates OpenID Connect (OIDC) ID tokens
• iam.serviceAccounts.signJwt signs JSON Web Tokens (JWTs)
• iam.serviceAccounts.signBlob signs binary blobs
• iam.serviceAccounts.implicitDelegation allows service accounts to participate in a delegation chain

The Service Account OpenID Connect Identity Token Creator role (roles/iam.serviceAccountOpenIdTokenCreator) is the narrow role for creating only OIDC ID tokens. The role includes only iam.serviceAccounts.getOpenIdToken, so it enforces least privilege when a workload needs identity proof rather than Google API authorization. Use this role when the caller only needs to mint ID tokens, and use Service Account Token Creator when the caller also needs access tokens, signed JWTs, or signed blobs.

The impersonation roles differ from attachment and federation roles in purpose and effect:

3.3Generating Short-Lived Credentials

Generation of short-lived credentials depends on the IAM and Service Account Credentials APIs being enabled and on the caller holding the matching role on PRIV_SA. A user caller typically runs gcloud iam service-accounts add-iam-policy-binding or uses the Permissions tab for PRIV_SA, while a workload caller uses Application Default Credentials (ADC) or the --impersonate-service-account flag, which makes gcloud CLI automatically create short-lived credentials. In most cases the caller service account and PRIV_SA cannot be the same, because the Service Account Credentials API prohibits self-impersonation that uses a short-lived credential for a service account to generate a new access token for that same service account.

The Service Account Credentials API can create four types of short-lived credentials for a service account:

• OAuth 2.0 access tokens authenticate to most Google APIs and carry the permissions of PRIV_SA
• OpenID Connect (OIDC) ID tokens prove the identity of PRIV_SA and are accepted by a limited set of services such as Cloud Run
• Self-signed JWTs authenticate to some Google APIs and API Gateway without contacting the authorization server
• Self-signed binary blobs securely transmit arbitrary binary data, such as signing Cloud Storage signed URLs, using the Google-managed private key held in escrow

This set covers broad API authorization, service-specific identity proof, direct JWT presentation, and signed binary payloads. Generation always preserves the boundary that impersonation mints a credential for PRIV_SA without changing the IAM grants that PRIV_SA already holds on target resources.

3.4Credential Access Boundaries and Token Downscoping

Credential Access Boundaries implement downscoping for bearer access tokens that might be shared or leaked. Google access tokens are bearer tokens, which means use is not tied to a particular application, so any application or actor that obtains the token can use it the same way as the original holder. Downscoping limits the damage from sharing or leakage by exchanging a broad OAuth 2.0 access token for a new token whose permissions are the intersection of the principal's IAM grants and the access boundary.

A Credential Access Boundary is a JSON object that contains a list of access boundary rules defining the upper bound of available permissions. The boundary can subtract permissions but cannot add permissions the principal does not already have, so the principal must first receive IAM roles on the bucket or a higher-level resource such as the project. For example, if the downscoped token must create objects, both the IAM grant and the boundary must include storage.objects.create, while a broader grant such as Storage Object Admin is still reduced to only what the boundary allows. Downscoping is supported only for Cloud Storage and only for OAuth 2.0 access tokens, not for ID tokens, JWTs, or blobs.

Creating a downscoped credential follows an ordered exchange where each step depends on the prior step:

1. Grant IAM roles: Grant the user or service account the IAM roles that contain the needed Cloud Storage permissions.
2. Define the boundary: Create the Credential Access Boundary object with rules that cap permissions and resource access to the minimum required.
3. Create a source token: Generate a standard OAuth 2.0 access token for the user or service account through impersonation.
4. Exchange the token: Send the source token to the Security Token Service (STS) with the boundary, and STS returns a new downscoped access token for Cloud Storage requests.

This pattern supports a token-broker design where one supervisor component holds Service Account Token Creator on dedicated single-purpose service accounts and issues downscoped tokens to other application parts. Data flows from the broker to the downstream component as a downscoped token, so each job receives only the bucket and permission subset it needs at that time. Apply downscoping whenever a token crosses an application or component boundary.

3.5Governance, Audit, and Privilege-Escalation Controls

Governance of impersonation relies on audit visibility and on preventing standing privilege from accumulating in service accounts. When short-lived credentials impersonate a service account, most Google Cloud services write Cloud Audit Logs entries that show both the service account being impersonated and the identity that created the short-lived credentials. This dual-identity logging lets reviewers trace which caller minted the token and which PRIV_SA authorized the action, although App Engine and Google Kubernetes Engine do not log the creator identity.

Least-privilege governance also requires controlling impersonation chains across projects and over time. Lateral movement occurs when a service account in one project can impersonate a service account in another project, allowing a principal to move from project to project and gain permissions through chained impersonation. Attaching a service account from one project to a resource in another project does not constitute lateral movement because attachment alone grants no impersonation permission. Use role recommendations to remove unused permissions from over-provisioned service accounts and review lateral movement insights to break unintended cross-project impersonation paths.

Key Facts

• OAuth 2.0 access tokens authenticate a service account to most Google APIs with OAuth scopes and live 5 minutes to 12 hours with a default maximum of 1 hour.
• OIDC ID tokens prove service account identity to a specific service URL through an audience claim and require the Service Account OpenID Connect Identity Token Creator role on the privilege-bearing service account.
• Workload Identity Federation exchanges an external AWS, Azure, OIDC, or SAML assertion at the Security Token Service for a short-lived federated token without using downloadable service account keys.
• Service Account Token Creator allows creating access tokens, ID tokens, signed JWTs, and signed blobs, while Service Account User only allows attaching a service account to a resource and does not allow impersonation.
• Credential Access Boundaries downscope an OAuth 2.0 access token for Cloud Storage to the intersection of the principal's IAM grants and the boundary rules.