feat(auth): implement regional access boundary support for standalone JWT and async service accounts

[nbayati]

This PR implements the following changes:

• Add RAB support to async service account credential type, by providing async manager and fetching methods.
• Update unit tests to accept both mtls and standard lookup endpoint urls.
• Refactor before_request to use a _after_refresh hook so we don't have to override the method.
• Add RAb support for self signed jwt flow through jwt.py
• some small enhancements for test coverage and backward compatibility

[gemini-code-assist]

Code Review

This pull request implements asynchronous support for Regional Access Boundary (RAB) management, including background refresh tasks and mTLS endpoint support. Key changes include the addition of _AsyncRegionalAccessBoundaryRefreshManager, updates to JWT and service account credentials to handle RAB state during cloning and serialization, and comprehensive test coverage for these new flows. However, a critical issue was identified where the refresh method in google/auth/jwt.py was renamed to _perform_refresh_token, which will break token updates as the base class expects a refresh method. Additionally, a typo was found in a test assertion URL.

[lsirac]

_jwt_async.OnDemandCredentials inherits from jwt.OnDemandCredentials first. Because jwt.OnDemandCredentials implements before_request synchronously, Python's MRO resolves before_request to the synchronous parent, shadowing the async base.
When called via the experimental async HTTP transport (_aiohttp_requests.py), which has no initialization type-checking and explicitly awaits before_request(...), the synchronous method executes, returns None, and the event loop attempts to await None, raising:
TypeError: object NoneType can't be used in 'await' expression

[nbayati]

Thanks for catching this. I've resolved this by adding an async def before_request override to the OnDemandCredentials class that delegates to the parent class, and updated the corresponding async test cases to properly await the call.

As a side note, I have OnDemandCredentials on my radar as a class that might need to support RAB in the future, but I have decided to keep it out of scope for this PR.

[lsirac]

Ok sounds good. I think we have a few open items to follow up on IIRC. Where are they being tracked?

[nbayati]

I'm tracking the additional credential types in the RAB google sheet tracker for a follow up release.
For the items that weren't RAB specific, I have made a github issue:

• Updating token grant methods is tracked in Auth: Align async token endpoint request helper with google.auth.aio.transport spec #17139.
• Migrating the remaining endpoints is tracked in google-auth: Fix static module-level IAM endpoints and propagate mTLS certificates to internal helper sessions #17282.

[nbayati]

Note to reviewers regarding mTLS transport gap:
Please note that while the RAB implementation in this PR dynamically switches endpoints to iamcredentials.mtls.googleapis.com when mTLS is enabled, the actual mTLS handshake will silently fall back to standard TLS (or fail under strict CBA enforcement) due to a library-wide transport gap.

The internal helper transport adapter (self._auth_request / self._request) passed to _regional_access_boundary_utils.py is not configured with the client certificate.

I have filed a tracking issue to address this transport gap: #17282

Because resolving the transport gap requires structural changes to google-auth's transport adapter initialization (requests.py and urllib3.py), we will track and merge the transport fix separately to keep the scope of this PR clean and focused on the core RAB logic. Once the transport issue is resolved, the RAB lookups in this feature will automatically execute over secure mTLS channels.

[lsirac]

Great job!

last thing - consider validating lookup response, but can be done in a followup

[daniel-sanche]

A few comments from my first pass. I'll try to take another look soon

[daniel-sanche]

This seems confusing. If it's async, is it really blocking?

[nbayati]

In this context, "blocking" refers to the logical flow of the request (i.e., we wait for the RAB lookup to complete before proceeding with the main request), as opposed to the background refresh mode. In the async implementation, this is achieved by awaiting the lookup, which suspends the coroutine but does not block the OS thread. The name matches the _use_blocking_regional_access_boundary_lookup configuration.

[daniel-sanche]

I'd suggest trying to clarify that in the docstring

[daniel-sanche]

I find tracing some of these functions a bit confusing. There's a _lookup_regional_access_boundary_request and _lookup_regional_access_boundary_request_no_throw, but it seems like neither of them throw?

I see this is the same pattern from the sync files though, so it can probably stay as-is

[nbayati]

Correct, neither throws. The _no_throw version handles the low-level exceptions (timeouts, transport errors) and returns the detailed status tuple (status, data, retryable) used for retry logic. The other function acts as a wrapper that simplifies the interface by returning just data or None.

We kept this pattern to remain consistent with the sync implementation in _client.py.

[lsirac]

We should add a test for external account + SA impersonation flow. This implementation will create an Impersonated cred with a new RAB manager. I think we may be dropping state that is needed (e.g. is blocking lookup enabled?).

Please add some coverage for this + validate that we are properly propagating the relevant RAB data.

[nbayati]

Good catch! We were indeed dropping the blocking flag. I double checked the properties and I think that's the only thing we should propagate. Our helper method in the base class copies the blocking flag and the RAB data, but I decided not to use that, since the RAB data of the external account if it was seeded, would not necessarily be the RAB data of the impersonated account.

I resolved this by propagating the blocking RAB lookup configuration (_use_blocking_regional_access_boundary_lookup) from the outer ExternalAccountCredentials to the inner ImpersonatedCredentials during initialization in _initialize_impersonated_credentials. Also added a unit test (test_refresh_impersonation_propagates_rab_config in tests/test_external_account.py) to verify the propagation.

[lsirac]

I think is_email is overpromising here for what we're checking. I think we can rename to is_service_account_email and implement with a simple regex check

[nbayati]

Done! I renamed the method and used ^[^@]+@[^@]+\.[^@]+$ which was recommended in the design for all SDKs to follow.

[daniel-sanche]

LGTM

[lsirac]

LGTM