feat: Regional Access Boundary Update by vverman · Pull Request #1880 · googleapis/google-auth-library-java

vverman · 2026-01-25T21:35:27Z

Contains changes for the feature Regional Access Boundary (Previously Called Trust Boundaries).

The following are salient changes:

Calls to refresh RAB are now all async and in a separate thread.
Logic for refreshing RAB now exists in its own class for cleaner maintenance.
Self-signed jwts are within scope.
Changes to how we trigger RAB refresh and deal with refresh errors.

…pe. Updated tests.

…rors are now retryable.

lqiu96 · 2026-02-05T04:31:09Z

oauth2_http/java/com/google/auth/http/HttpCredentialsAdapter.java

    return false;
  }
+
+  private boolean handleStaleRegionalAccessBoundaryError(


IIUC, this method looks like it's doing two things:

Checking if there we should check for stale RAB Error

And if so, checking if there is a stable RAB error message

Can this be broken into two helper methods to simply this? e.g. perhaps somehting like shouldhandleStableRAB... and handleStaleRAB...

Done, thanks for the suggestion.

lqiu96 · 2026-02-05T04:39:07Z

oauth2_http/java/com/google/auth/http/HttpCredentialsAdapter.java

+    try {
+      // Check for the stale regional access boundary error message in the response body.
+      // Note: This consumes the response stream.
+      String content = response.parseAsString();


I think this should be fine since this is part of the flow to initialize this request. But if it consumes the content and closes the stream, I wonder if this may break anything that tries to consume it later.

The reason is that there is no easy way to create a copy of an HTTP response or peek into its contents without consuming the response stream.

I decided to implement it for the reason that this flow makes a few assumptions before consuming the error:

The HTTP code is a 406 which is relatively uncommon

The request actually carried RAB headers

This should ensure that for the majority of scenarios this downstream error won't be a problem.

lqiu96 · 2026-02-05T04:41:51Z

oauth2_http/java/com/google/auth/oauth2/GoogleCredentials.java

+   * @param token The access token to use for the refresh.
+   * @throws IOException If getting the universe domain fails.
+   */
+  public final void reactiveRefreshRegionalAccessBoundary(@Nullable URI uri, AccessToken token)


are the uri and accesstoken parameters used here?

Got rid of uri thanks for the catch.

oauth2_http/java/com/google/auth/oauth2/GoogleCredentials.java

oauth2_http/java/com/google/auth/oauth2/RABManager.java

lqiu96 · 2026-02-06T21:58:37Z

oauth2_http/java/com/google/auth/oauth2/RegionalAccessBoundaryManager.java

+    // this thread "won the race" and is responsible for starting the background task.
+    // All other concurrent threads will return false and exit immediately.
+    if (refreshFuture.compareAndSet(null, future)) {
+      CompletableFuture.runAsync(


Can you use Guava's ListeningFuture to keep with the rest of the auth-library?

Since this is called from both getReqestMetadata(...) methods (one of which takes in an executor), I think we'll also need to respect that.

I think this method should take in the executor as a param

The way I understand: the executor in getRequestMetadataAsync is used to provide a pool of threads to execute the token refresh in the background.

My initial assumption with doing this via CompletableFuture was that the user might want the background thread to exclusively focus on token refresh and not the RAB refresh.

If we are okay with the user's background thread waiting longer for the RAB to refresh then I am okay with making this change.

lqiu96 · 2026-02-06T22:08:46Z

oauth2_http/java/com/google/auth/oauth2/RegionalAccessBoundary.java

+    if (accessToken.getExpirationTime() != null
+        && accessToken.getExpirationTime().before(new Date())) {


Since we can inject the Clock object for tests, can we do comparisons using the clock object instead of using new Date()

e.g. something like accessToken.getExpirationTime().getInstant().isBefore(clock.getInstant())?

used getExpirationTimeMilis in the clock object.

lqiu96 · 2026-02-06T22:15:51Z

oauth2_http/java/com/google/auth/oauth2/GoogleCredentials.java

+  }
+
+  /**
+   * Refreshes the Regional Access Boundary if it is expired or not yet fetched.


nit: the method name and docs isn't fully accurate as it does more than just checking if the boundary has expired.

If possible, can this be broken into two methods:

shouldRefresh...()

refresh...()

I think it might be easier to test as well. Let me know what you think

lqiu96 · 2026-02-06T22:17:36Z

oauth2_http/java/com/google/auth/oauth2/GoogleCredentials.java

+      metadata.put(
+          RegionalAccessBoundary.HEADER_KEY, Collections.singletonList(rab.getEncodedLocations()));
+    }
+    refreshRegionalAccessBoundaryIfExpired(uri, getAccessToken());


IIUC this correctly, refreshRegionalAccessBoundaryIfExpired is not blocking right?

Shouldn't we have a blocking variant to ensure this gets the proper headers?

We don't wish to block the main request's flow for RAB refresh. The request will still succeed without RAB headers they could face some added latency due to being routed to non-mandatory regions.

lqiu96 · 2026-02-06T22:30:42Z

oauth2_http/java/com/google/auth/oauth2/RegionalAccessBoundaryManager.java

+    currentCooldownMillis = INITIAL_COOLDOWN_MILLIS;
+  }
+
+  synchronized boolean isCooldownActive() {


This method is synchronized but is going to be called often due it being called from getRequestMetadata() call. Logic doesn't run that long but it is a possibility for contention.

I'll need think about this a bit more, but I wonder if we can format this so it doesn't need a lock.

One consideration could be to have the cooldown variable as an atomic reference reducing the need for the synchronized function. I too can explore this a bit.

Added async logic for RAB refresh/ Now self-signed JWT are in RAB sco…

1b160a8

…pe. Updated tests.

vverman requested review from a team as code owners January 25, 2026 21:35

vverman requested a review from a team January 25, 2026 21:35

product-auto-label bot added the size: xl Pull request size is extra large. label Jan 25, 2026

Lint fixes.

525ae6d

vverman requested review from lqiu96 and nbayati January 25, 2026 21:49

Url for RAB to include only GDU. Only 500, 502, 503 and 504 lookup er…

b7058ea

…rors are now retryable.

lqiu96 changed the base branch from feat-tb-sa to feat/agentic-identities-cloudrun February 3, 2026 19:16

lqiu96 requested a review from a team as a code owner February 3, 2026 19:16

lqiu96 reviewed Feb 5, 2026

View reviewed changes

oauth2_http/java/com/google/auth/oauth2/GoogleCredentials.java Outdated Show resolved Hide resolved

lqiu96 reviewed Feb 5, 2026

View reviewed changes

oauth2_http/java/com/google/auth/oauth2/RABManager.java Outdated Show resolved Hide resolved

lqiu96 reviewed Feb 6, 2026

View reviewed changes

vverman changed the base branch from feat/agentic-identities-cloudrun to feat-tb-sa February 6, 2026 22:40

Addressed some PR comments.

e8832a1

		if (accessToken.getExpirationTime() != null
		&& accessToken.getExpirationTime().before(new Date())) {

Conversation

vverman commented Jan 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants