GCS: support bearer-token auth in parse_url_opts without bypassing default option handling

[siddharthmittal13]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

We need to access gs:// paths using an explicit OAuth bearer token.

Today, the normal GCS path goes through object_store::parse_url_opts. However, there does not appear to be a supported way to pass a bearer token through that standard option-parsing flow. Because of that, downstream users have to bypass the default path and manually construct a GoogleCloudStorageBuilder with a custom credential provider.

The problem with that workaround is that it no longer preserves full behavior parity with the default gs handling. The manual builder path can forward recognized GoogleConfigKey options, but anything else handled by the standard parse_url_opts path may be lost or silently ignored.

So the challenge is: we want bearer-token authentication for GCS without having to replace the default GCS option-handling path.

Describe the solution you'd like

A supported way to provide a GCS bearer token while still using the standard parse_url_opts flow.

For example, one of these would solve the problem:

• support a bearer-token option in the GCS parsing path
• allow a credential override to be passed into the GCS builder/parser
• provide a standard API for overriding credentials without bypassing the normal option handling

The key requirement is that bearer-token auth should integrate with the existing gs option parsing instead of forcing downstream code into a custom builder path.

Describe alternatives you've considered

The alternative we considered was manually creating a GoogleCloudStorageBuilder and injecting a credential provider with the bearer token.

That works for authentication, but it has downsides:

• it bypasses parse_url_opts
• it requires downstream code to reimplement part of the standard GCS setup
• it may silently ignore extra options that would otherwise be handled by the default path

So it works as a workaround, but not as a clean or robust long-term solution.

Additional context

This came up in a downstream integration where we added custom handling for a google_bearer_token option only for gs:// URLs.

That downstream implementation highlighted the API gap: once we switch to a custom builder to support bearer-token auth, we are no longer guaranteed to preserve all behavior from the default parse_url_opts path.