Using Credential Access Boundary (DownScoped) Tokens

salmaan rashid
Mar 2 · 4 min read

Credential Access Boundary is a policy language that you can use to downscope the accessing power of your GCP short-lived credentials. You can define a Credential Access Boundary that specifies which resources the short-lived credential can access, as well as an upper bound on the permissions that are available on each resource

For example, if the parent Credential that represents user Alice has Read/Write access to GCS buckets A, B, C, you can exchange the Alice's credential for another credential that still identifies Alice but can only be used for Read against Bucket A and C.

Warning: (3/12/20): The following describes the beta release of Credential Access Boundary (DownScoped) Tokens on Google Cloud. This API is open but not documented yet. This article is intended to demonstrate this new capability and solicit feedback on enhancements users would like to see (for that, please just leave an issue/FR on github here )

DownScoped tokens are normally used in a tokenbroker/exchange service where you can mint a new restricted token to hand to a client. The sample usage and implementations below shows how to generate a downscoped token, extract the raw access_token, and then inject the raw token in another TokenSource.

** NOTE:**

  • DownScoped tokens currently only works for GCS buckets and cannot be applied yet at the bucket+prefix or object level.
  • The GCS bucket must be enabled with Uniform bucket-level access
  • Supported credentials: The only supported type of credential in Credential Access Boundary is OAuth2.0 access token.

You can find the git version of this article here:

Defining a boundary rule:

You downscope a token by transmitting that token to a google token endpoint along with a boundary rule describing the resources and roles the credential should be restricted to.

The definition of a boundary rule is just json:


  • AvailableResource (required) This is the GCP resource (such as organization, folder, project, bucket, etc) to which access may be allowed (and allowed to resources below that resource if applicable). It must be in the format of a GCP Resource Name.
  • AvailablePermissions (required) This is a list of permissions that may be allowed for use on the specified resource or resources below the specified resource. The only supported value is IAM role with syntax: "inRole:roles/storage.admin"

As an example, the following would the token to just objectViewer on BUCKET_2:

Exchange the token

You now need to transmit the original access_token and the boundary rule to a google token-exchange endpoint: The response JSON will return a new token if the policy file is well formed.

Usage: curl

As a quick demonstration of this capability, create two GCS buckets and acquire an access_token that you can use to list objects in either bucket. Exchange that access_token for another access_token that can only be used on one of the two buckets:

  1. Create two buckets:

2. Create policy to only allow storage.objectViewer to BUCKET_2

3. Get existing access_token

4. Exchange access_token

(the following command uses jq to parse the response):

5. Use downscoped token

Try listing bucket contents using the new token…

as you’ll see, you can access BUCKET_2 but not BUCKET_1 since we're using the downscoped token


At the moment, no official google-auth-* library supports this capability. However, i've written up the implementations in the following languages which behave as if its just another credential type for any google cloud client libraries (well..just GCS at the moment).

  • golang: Use as
  • java: Use as com/google/auth/oauth2/DownScopedCredentials
  • python: Use as google/auth/downscoped_credentials

For example:


see java/src/main/java/com/google/auth/oauth2/

see python/google/auth/

You don’t have to use any of those libraries ofcourse!. If you manually exchange and acquire a downscoped token, you can ‘just apply’ it to several existing google-auth-* constructs that allows you to set the token:

Note, if you use these, the static access_token will not get refreshed automatically.

Usecase: TokenBroker

  1. A developer or workload (the requester) requests credentials to get access to certain GCP resources.
  2. The broker system identifies the service account that has access to the requested resources and gets a credential for that service account.
  3. Before handing off the credentials to the requestor, the broker system restricts the permissions on the credential to only what the token requester needs access to, by applying a Credential Access Boundary on the service account credentials by calling the CAB API.
  4. The broker system hands the downscoped credentials to the requester.
  5. The requester can now use those credentials to access GCP resources

This release has the following restrictions:

Thats it…this is just an alpha capability…do not use this in production yet!.

Again, the intent of this article is to get feedback…please add in any comments to the repo here

Google Cloud - Community

A collection of technical articles published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

salmaan rashid

Written by

Google Cloud - Community

A collection of technical articles published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

More From Medium

More from Google Cloud - Community

More from Google Cloud - Community

More from Google Cloud - Community

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade