Access resources from an OIDC identity provider

This document shows you how to use identity federation to access Google Cloud resources from an identity provider that supports OpenID Connect (OIDC).

Traditionally, applications running outside Google Cloud have used service account keys to access Google Cloud resources. Using identity federation, you can let an external identity impersonate a service account. This lets your workload access Google Cloud resources directly, using a short-lived access token, and eliminates the maintenance and security burden associated with service account keys.

Before you begin

  1. Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service (STS) APIs.

    Enable the APIs

  2. Ensure that you have the Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin) and Service Account Admin (roles/iam.serviceAccountAdmin) roles on the project.

    Alternatively, the IAM Owner (roles/owner) basic role also includes permissions to configure identity federation. You should not grant basic roles in a production environment, but you can grant them in a development or test environment.

  3. Update the organization policy for your organization to allow federation from the identity provider.

  4. Create a Google Cloud service account.

  5. Grant the service account access to call the Google Cloud APIs required by your workload.

Identity provider settings for OIDC

When you add an OIDC identity provider to your workload identity pool, you must provide the following:

  • An ID for the provider.

  • The provider's issuer URI. This typically takes the form https://example.com. Consult your provider's documentation on OIDC integration to find the URI.

  • A list of attribute mappings that map the claims on an external token to the attributes on a Google token. Use assertion to refer to the external credential, google for Google attributes, and attribute for custom attributes.

    There are two Google attributes: google.subject and google.groups. You can reference these attributes in IAM role bindings. google.subject also appears in Cloud Logging log entries.

    You must provide a mapping for google.subject. In general, we recommend mapping it to assertion.sub, which should provide a stable identifier for use in IAM role bindings. The mapping looks like this:

    google.subject=assertion.sub
    

    For more complex assertions, you can use the Common Expression Language. For example, if your workload identity pool contains multiple identity providers, you can append a prefix to disambiguate between them:

    google.subject="provider-a::" + assertion.sub
    

    The google.subject field cannot exceed 127 characters.

    You can also specify custom attributes. For example, the following maps assertion.foo to attribute.bar:

    attribute.bar=assertion.foo
    

    Consult your provider's documentation on access tokens for a complete list of claims you can reference.

    To reference a specific part of a claim in an expression, use the CEL extract() function, which extracts a value from a claim based on a template you provide. To learn more about extract(), see Extracting values from attributes.

    To check if a credential contains an claim, use the has() function.

  • A list of allowed audiences specifying what values the aud field on the external credential can contain. You can configure a maximum of 10 audiences, each up to 256 characters. Consult your provider's documentation for information on their default values for aud.

    Alternatively, if your identity provider allows you to configure a custom value for aud, you can leave the allowed audiences parameter empty, and set the value of aud to the full resource name of your workload identity provider. The HTTP prefix is optional; for example:

    //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
    https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
    

    In either case, any token exchange requests that don't contain one of the allowed values are rejected.

You can also provide several optional parameters:

  • A display name and description.

  • An attribute condition specifying attributes that the principal must present. The attribute condition can apply to claims on the external credential, or attributes on the Google credential. Any request that does not meet the attribute condition is rejected.

    Attribute conditions are formatted as a CEL expression that returns a boolean. For example, the following rejects requests from any identity that isn't a member of a specific group:

    GROUP in assertion.groups
    

    Using attribute conditions is strongly recommended if the identity provider is available to the general public. To learn more about common use cases, see Attribute conditions.

Create a workload identity pool and provider

You use a workload identity pool to organize and manage external identities. Workload identity pools are isolated from each other, but a single pool can impersonate any number of service accounts. In general, we recommend creating a new pool for each of your environments, such as development, staging, or production.

To create a new workload identity pool, you'll need to provide an ID. You can also provide an optional description and display name. The ID cannot begin with gcp-; this prefix is reserved for use by Google.

After you create the workload identity pool, you can add a workload identity pool provider. Each workload identity pool provider represents a specific identity provider. A single pool can contain multiple providers. To create the provider, you'll need the information described on this page in Identity provider settings for OIDC.

Console

  1. In the Cloud Console, go to the New workload provider and pool page.

    Go to New workload provider and pool

  2. Enter a name for the workload identity pool.

    The Cloud Console uses the name to create a pool ID. To change the pool ID, click Edit. You cannot change the pool ID later.

  3. Optional: Enter a description for the workload identity pool.

  4. Click Continue.

  5. In the Select a provider drop-down list, select OpenID Connect (OIDC), then click Continue.

  6. Enter a provider name.

    The Cloud Console uses the name to create a provider ID. To change the provider ID, click Edit. You cannot change the provider ID later.

  7. Enter the issuer URL for your provider, then click Continue.

  8. To configure the attribute mapping, click Edit mapping.

    Attribute mapping lets you use information about external identities to grant access to a subset of those identities. For OIDC identity providers, we recommend mapping google.subject to assertion.sub. Other mappings are optional.

    For details, see Identity provider settings for OIDC on this page.

  9. Optional: To provide an attribute condition, which specifies the identities that can authenticate, click Add condition and enter a valid Common Expression Language (CEL) expression. For details, see Attribute conditions.

  10. Click Save to create the workload identity pool and provider.

gcloud

To create a workload identity pool, use the gcloud iam workload-identity-pools create command:

gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"

The response looks like:

Created workload identity pool [POOL_ID].

To add a workload identity pool provider, use the gcloud iam workload-identity-pools providers create-oidc command:

gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER_URI" \
    --location="global" \
    --attribute-mapping="google.subject=assertion.sub"

The response looks like:

Created workload identity pool provider [PROVIDER_ID].

REST

To create a workload identity pool, do the following:

The projects.locations.workloadIdentityPools.create method creates a workload identity pool.

HTTP method and URL:

POST https://iam.googleapis.com/v1/projects/project-id/locations/global/workloadIdentityPools?workloadIdentityPoolId=pool-id

Request JSON body:

{
  "description": "description",
  "display-name": "display-name"
}

To send your request, expand one of these options:

The method returns a long-running Operation similar to the following:

{
  "name": "projects/project-number/locations/global/workloadIdentityPools/pool-id/operations/operation-id"
}

To add a workload identity pool provider, do the following:

The projects.locations.workloadIdentityPools.providers.create method adds an OIDC identity provider.

HTTP method and URL:

POST https://iam.googleapis.com/v1/projects/project-id/locations/global/workloadIdentityPools/pool-id/providers?workloadIdentityPoolProviderId=provider-id

Request JSON body:

{
  "issuerUrl": "issuer-uri"
}

To send your request, expand one of these options:

The method returns a long-running Operation similar to the following:

{
  "name": "projects/project-number/locations/global/workloadIdentityPools/pool-id/providers/provider-id/operations/operation-id"
}

Allow external identities to impersonate a service account

External identities can't access most Google Cloud resources directly. Instead, you let the identities impersonate a service account by granting them the Workload Identity User role (roles/iam.workloadIdentityUser) on the service account. When the external identities impersonate a service account, they have the same roles and permissions as the service account.

To grant the Workload Identity User role to external identities, do the following:

Console

Before you grant the Workload Identity User role, decide which identities you will allow to impersonate the service account. You can grant the role to all identities in the workload identity pool, or to a subset of these identities based on attribute mapping:

Identities Attribute name Attribute value
Single identity subject SUBJECT_NAME
All identities with a specific attribute value ATTRIBUTE_NAME ATTRIBUTE_VALUE

Then grant access to the service account, and optionally, download a configuration file for generating credentials automatically:

  1. In the Cloud Console, go to the Workload Identity Pools page.

    Go to Workload Identity Pools

  2. Find the workload identity pool that contains the external identities, then click its Edit icon. The Cloud Console shows details about the workload identity pool.

  3. Click Grant access.

  4. In the Service account drop-down list, select the service account that the external identities will impersonate.

  5. Choose which identities in the pool can impersonate the service account.

    To allow all identities to impersonate the service account, select All identities in the pool.

    To allow a subset of identities to impersonate the service account, select Only identities matching the filter, then do the following:

    1. In the Attribute name drop-down list, select the attribute that you want to evaluate.

      Only mapped attributes appear on the list. The google. and attribute. prefixes are not shown.

    2. In the Attribute value field, enter the expected value of the attribute.

  6. Click Save.

    If the identities already had access to the service account, the Cloud Console shows details about the workload identity pool. You can skip the remaining steps.

    If the identities gained access to the service account, the Cloud Console shows the Configure your application dialog.

  7. Optional: To download a configuration file for generating credentials automatically, do the following:

    1. In the Provider drop-down list, select the provider that contains the external identities that will impersonate the service account.

    2. Click Download config to download a JSON configuration file.

  8. Click Dismiss.

gcloud

Before you grant the Workload Identity User role, decide which identities you will allow to impersonate the service account. You can grant the role to all identities in the workload identity pool, or to a subset of these identities based on attribute mapping:

Identities Member format
Single identity principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_NAME
All identities with a specific attribute value principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
All identities in a pool principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*

Then run the gcloud iam service-accounts add-iam-policy-binding command:

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="MEMBER"

Replace the following values:

  • SERVICE_ACCOUNT_EMAIL: The email address for the service account.
  • MEMBER: The external identities that will impersonate the service account.

REST

Before you grant the Workload Identity User role, decide which identities you will allow to impersonate the service account. You can grant the role to all identities in the workload identity pool, or to a subset of these identities based on attribute mapping:

Identities Member format
Single identity principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_NAME
All identities with a specific attribute value principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
All identities in a pool principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*

Then use the read-modify-write pattern to update the policy:

  1. Read the service account's current IAM policy.
  2. Modify the policy to grant the role.
  3. Write the updated policy.

Read the service account's IAM policy.

The serviceAccounts.getIamPolicy method gets a service account's IAM policy.

Before using any of the request data below, make the following replacements:

  • PROJECT_ID: Your Google Cloud project ID. Project IDs are alphanumeric strings, like my-project.
  • SA_ID: The ID of your service account. This can either be the service account's email address in the form SA_NAME@PROJECT_ID.iam.gserviceaccount.com, or the service account's unique numeric ID.

  • POLICY_VERSION: The policy version to be returned. Requests should specify the most recent policy version, which is policy version 3. See Specifying a policy version when getting a policy for details.

HTTP method and URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:getIamPolicy

Request JSON body:

{
  "options": {
    "requestedPolicyVersion": POLICY_VERSION
  }
}

To send your request, expand one of these options:

You should receive a JSON response similar to the following:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

When there is no existing policy, the response contains only the default etag. If you get this response, add a version field, set to 3, and a bindings field, set to an empty array.

Modify the policy to grant the appropriate roles to your members.

To grant a role, you modify the bindings array from the response body:

  • If a binding for the role does not exist, add a new object to the bindings array that defines the role you want to grant and the member you want to grant it to.
  • If a binding already exists for the role, add the new member to the list of existing members.

Example:

To grant the Workload Identity User role (roles/iam.workloadIdentityUser) to all identities in the pool, change the example shown in the previous step as follows:

{
  "version": 1,
  "etag": "BwUqLaVeua8=",
  "bindings": [
    {
      "role": "roles/iam.workloadIdentityUser",
      "members": [
        "principalSet://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/my-pool/*"
      ]
    },
    {
      "role": "roles/iam.serviceAccountAdmin",
      "members": [
        "user:admin@example.com"
      ]
    }
  ]
}

Write the updated policy.

The serviceAccounts.setIamPolicy method sets an updated IAM policy for the service account.

Before using any of the request data below, make the following replacements:

  • PROJECT_ID: Your Google Cloud project ID. Project IDs are alphanumeric strings, like my-project.
  • SA_ID: The ID of your service account. This can either be the service account's email address in the form SA_NAME@PROJECT_ID.iam.gserviceaccount.com, or the service account's unique numeric ID.

  • POLICY: A JSON representation of the policy that you want to set. For more information about the format of a policy, see the Policy reference.

    For example, to set the policy shown in the previous step, replace policy with the following:

    {
      "version": 1,
      "etag": "BwUqLaVeua8=",
      "bindings": [
        {
          "role": "roles/iam.workloadIdentityUser",
          "members": [
            "principalSet://iam.googleapis.com/projects/1234567890123/locations/global/workloadIdentityPools/my-pool/*"
          ]
        },
        {
          "role": "roles/iam.serviceAccountAdmin",
          "members": [
            "user:admin@example.com"
          ]
        }
      ]
    }
    

HTTP method and URL:

POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SA_ID:setIamPolicy

Request JSON body:

{
  "policy": POLICY
}

To send your request, expand one of these options:

The response contains the updated policy.

Generate Google credentials

If you use a supported client library, you can configure the client library so that it generates Google credentials automatically. Alternatively, you can generate an OIDC ID token manually, then exchange the token for Google credentials.

When possible, we recommend that you generate credentials automatically, so that you do not need to implement the token-exchange process yourself.

Automatically generate credentials

If you access Google Cloud with a client library for one of the following languages, you can configure the client library to automatically generate credentials by using identity federation:

C++

Most of the Google Cloud Client Libraries for C++ support identity federation by using a ChannelCredentials object, which is created by calling grpc::GoogleDefaultCredentials(). To initialize this credential, you must build the client libraries with version 1.36.0 or later of gRPC.

The Cloud Storage Client Library for C++ uses the REST API, not gRPC, so it does not support identity federation.

Go

Client libraries for Go support identity federation if they use version v0.0.0-20210218202405-ba52d332ba99 or later of the golang.org/x/oauth2 module.

To check which version of this module your client library uses, run the following commands:

cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2

Java

Client libraries for Java support identity federation if they use version 0.24.0 or later of the com.google.auth:google-auth-library-oauth2-http artifact.

To check which version of this artifact your client library uses, run the following Maven command in your application directory:

mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http

Node.js

Client libraries for Node.js support identity federation if they use version 7.0.2 or later of the google-auth-library package.

To check which version of this package your client library uses, run the following command in your application directory:

npm list google-auth-library

When you create a GoogleAuth object, you can specify a project ID, or you can allow GoogleAuth to find the project ID automatically. To find the project ID automatically, the service account in the configuration file must have the Browser role (roles/browser), or a role with equivalent permissions, on your project. For details, see the README for the google-auth-library package.

Python

Client libraries for Python support identity federation if they use version 1.27.0 or later of the google-auth package.

To check which version of this package your client library uses, run the following command in the environment where the package is installed:

pip show google-auth

To specify a project ID for the authentication client, you can set the GOOGLE_CLOUD_PROJECT environment variable, or you can allow the client to find the project ID automatically. To find the project ID automatically, the service account in the configuration file must have the Browser role (roles/browser), or a role with equivalent permissions, on your project. For details, see the user guide for the google-auth package.

To configure the client library to generate credentials automatically, you create a JSON configuration file. You can create this file with the Cloud Console or the gcloud tool.

The configuration file specifies how the client library will get tokens from the identity provider. There are a few different ways for the client library to get tokens:

  • File-sourced credentials: Tokens are loaded from a file. Another process must refresh this file with a new OIDC token before the old token expires. For example, if the token has a lifetime of 1 hour, you must refresh the file before it is 1 hour old.
  • URL-sourced credentials: Tokens are loaded from a local server with an endpoint that responds to HTTP GET requests. The response must be an OIDC ID token, either in plain text or in JSON format.

Console

First, follow the instructions on this page to allow external identities to impersonate a service account. You can then create a JSON configuration file for any service account that the external identities can impersonate.

To create a JSON configuration file, do the following:

  1. In the Cloud Console, go to the Workload Identity Pools page.

    Go to Workload Identity Pools

  2. Find the workload identity pool that contains the identity provider you want to use, then click its Edit icon. The Cloud Console shows details about the workload identity pool.
  3. Click Connected service accounts.
  4. Find the service account you want to use, then click Download.
  5. In the Provider drop-down list, select the provider that contains the OIDC identities that will impersonate the service account.
  6. In the OIDC ID token path box, enter one of the following:

    • For file-sourced credentials: The filepath where OIDC ID tokens will be stored.
    • For URL-sourced credentials: The URL that provides OIDC ID tokens in response to HTTP GET requests.
  7. In the Format type drop-down list, select txt for text format or json for JSON format.

    If you select json, confirm that the value in the Subject token field name box matches the JSON field name that contains the token. Update the value as necessary.

  8. Click Download config to download the JSON configuration file, then click Done.

If you are using URL-sourced credentials, and you want to include specific HTTP headers in the request, you can add these headers to the configuration file:

  1. Open the configuration file in a text editor, and find the headers field. It should look similar to the following:

    "headers": {},
    
  2. Add the HTTP headers to the headers object as key-value pairs. Each key and value must be enclosed in double quotes.

    For example, to send the X-Example-One header with the value test and the X-Example-Two header with the value example, add the following:

    "headers": {
      "X-Example-One": "test",
      "X-Example-Two": "example"
    },
    
  3. Save your changes to the configuration file.

gcloud

To use file-sourced credentials, run the gcloud iam workload-identity-pools create-cred-config command to generate the configuration file. The --credential-source-type flag is optional; the --credential-source-field-name flag is optional unless --credential-source-type is json:

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --output-file=CONFIGURATION_FILEPATH \
    --credential-source-file=TOKEN_FILEPATH \
    --credential-source-type=SOURCE_TYPE \
    --credential-source-field-name=FIELD_NAME

Replace the following values:

  • PROJECT_NUMBER: The numeric ID for the project.
  • POOL ID: The ID for the workload identity pool.
  • PROVIDER_ID: The ID for the workload identity pool provider.
  • SERVICE_ACCOUNT_EMAIL: The email address of the service account to impersonate.
  • CONFIGURATION_FILEPATH: The filepath for the configuration file.
  • TOKEN_FILEPATH: The filepath where OIDC ID tokens will be stored.
  • SOURCE_TYPE: The format of the OIDC ID token file. Set to text or json. Defaults to text.
  • FIELD_NAME: For JSON token files, the JSON field name that contains the token. Required if --credential-source-type is json.

To use URL-sourced credentials, run the gcloud iam workload-identity-pools create-cred-config command to generate the configuration file. The --credential-source-headers and --credential-source-type flags are optional; the --credential-source-field-name flag is optional unless --credential-source-type is json:

gcloud iam workload-identity-pools create-cred-config \
    projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID \
    --service-account=SERVICE_ACCOUNT_EMAIL \
    --output-file=CONFIGURATION_FILEPATH \
    --credential-source-url="TOKEN_URL" \
    --credential-source-headers="KEY_1=VALUE_1,KEY_2=VALUE_2" \
    --credential-source-type=source_type \
    --credential-source-field-name=field_name

Replace the following values:

  • PROJECT_NUMBER: The numeric ID for the project.
  • POOL_ID: The ID for the workload identity pool.
  • PROVIDER_ID: The ID for the workload identity pool provider.
  • SERVICE_ACCOUNT_EMAIL: The email address of the service account to impersonate.
  • CONFIGURATION_FILEPATH: The filepath for the configuration file.
  • TOKEN_URL: The URL that provides OIDC ID tokens in response to HTTP GET requests.
  • KEY_1, KEY_2: The name of an HTTP header to include in the request.
  • VALUE_1, VALUE_2: The value of an HTTP header to include in the request.
  • SOURCE_TYPE: The format of the OIDC token file. Set to text or json. Defaults to text.
  • FIELD_NAME: For JSON token files, the field name that contains the token. Required if --credential-source-type is json.

After you generate the configuration file, set the environment variable GOOGLE_APPLICATION_CREDENTIALS to the filepath for the configuration file. This environment variable tells the client library to use Application Default Credentials to authenticate. For details, see Finding credentials automatically.

Manually exchange credentials

Once your external identity has the ability to impersonate a service account, you can manually exchange its credentials for Google credentials.

To exchange credentials:

  1. Obtain an OIDC ID token from your identity provider (consult your identity provider's documentation for detailed instructions).

  2. Pass the OIDC ID token to the Security Token Service token() method to get a federated access token:

    REST

    The token method exchanges a third-party token for a Google token.

    Before using any of the request data below, make the following replacements:

    • PROJECT_NUMBER: Your Google Cloud project number.
    • POOL_ID: The ID of the workload identity pool you created.
    • PROVIDER_ID: The ID of the identity provider you configured.
    • ID_TOKEN: The token from the identity provider.

    HTTP method and URL:

    POST https://sts.googleapis.com/v1/token

    Request JSON body:

    {
      "audience": "//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID",
      "grantType": "urn:ietf:params:oauth:grant-type:token-exchange",
      "requestedTokenType": "urn:ietf:params:oauth:token-type:access_token",
      "scope": "https://www.googleapis.com/auth/cloud-platform",
      "subjectTokenType": "urn:ietf:params:oauth:token-type:jwt",
      "subjectToken": "ID_TOKEN"
    }
    

    To send your request, expand one of these options:

     

    The method returns a federated token.

  3. Call generateAccessToken() to exchange the federated token for a service account access token. A limited number of Google Cloud APIs support federated tokens; all Google Cloud APIs support service account access tokens.

    REST

    The Service Account Credentials API's serviceAccounts.generateAccessToken method generates an OAuth 2.0 access token for a service account.

    Before using any of the request data below, make the following replacements:

    • PROJECT_ID: Your Google Cloud project ID. Project IDs are alphanumeric strings, like my-project.
    • SA_ID: The ID of your service account. This can either be the service account's email address in the form SA_NAME@PROJECT_ID.iam.gserviceaccount.com, or the service account's unique numeric ID.
    • token: The federated access token.

    HTTP method and URL:

    POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SA_NAME@PROJECT_ID.iam.gserviceaccount.com:generateAccessToken

    Request JSON body:

    {
      "scope": [
        "https://www.googleapis.com/auth/cloud-platform"
      ]
    }
    

    To send your request, expand one of these options:

    If the generateAccessToken request was successful, the response body contains an OAuth 2.0 access token and an expiration time. The accessToken can then be used to authenticate a request on behalf of the service account until the expireTime has been reached:

    {
      "accessToken": "eyJ0eXAi...NiJ9",
      "expireTime": "2020-04-07T15:01:23.045123456Z"
    }
    

Once you have an access token for a service account, you can use it to call Google Cloud APIs by including the token in the Authorization header of your requests:

Authorization: Bearer SERVICE_ACCOUNT_ACCESS_TOKEN

The request is authorized as the service account.

What's next