Okta federation for BigQuery MCP servers reduces credential sprawl

At a glance

What this is: This is a hands-on guide to running a BigQuery-connected MCP server through Okta and Google Cloud federation instead of storing Google service-account keys locally.

Why it matters: It matters because IAM and NHI teams need to treat MCP access as governed identity flow, not as a place to hide static credentials inside server configs.

Context

An MCP server that reaches into BigQuery should be governed as an identity path, not just an application integration. The core problem in this architecture is credential sprawl: if the server relies on embedded JSON keys or shared service accounts, auditability and least privilege both degrade quickly.

Stacklok's example uses Okta, ToolHive, and Google Cloud federation to replace static server-side credentials with short-lived token exchange and per-user attribution. That matters for NHI governance because the operational question is no longer how to store a secret safely, but how to preserve identity boundaries across the proxy, the MCP server, and the cloud API.

The article is a configuration guide, but the security lesson is broader. Once MCP servers are allowed to speak to production data systems, identity lifecycle, token issuance, and workload permissions become part of the same control plane.

Key questions

Q: How should teams govern MCP servers that need access to cloud data sources?

A: Treat the MCP server as a controlled identity workload, not as a place to store long-lived credentials. Use federation, short-lived tokens, and explicit role mapping so access remains auditable, revocable, and tied to the real user or workload that initiated the request.

Q: Why do static service-account keys create extra risk in MCP integrations?

A: Static keys are durable, portable, and hard to constrain to a single session or user. Once they are embedded in configs or images, the server can keep working long after the original trust assumption has changed, which weakens revocation, attribution, and blast-radius control.

Q: What are the signs that an MCP federation design is not working properly?

A: Look for shared principals in logs, overbroad cloud roles, repeated manual key handling, or access that cannot be traced back to a named user. Those are all indicators that the design is still operating like a secret distribution problem rather than a governed identity flow.

Q: Should teams use federated access or embedded credentials for MCP workloads?

A: Federated access is the safer default when the workload reaches production systems and user-level accountability matters. Embedded credentials may look simpler, but they collapse identity boundaries, make offboarding harder, and leave too much standing privilege inside the server runtime.

Technical breakdown

How Okta federation changes MCP server authentication

In this flow, the MCP server itself does not hold Google Cloud keys. Okta issues an OIDC identity token to the authenticated user, ToolHive proxies the request, and Google STS exchanges that identity for scoped access to BigQuery through a workforce identity pool. That pattern is materially different from a service-account model because authorization happens through federated identity rather than through a reusable static secret. The practical effect is that the server can act on behalf of a user without needing to impersonate a durable machine principal.

Practical implication: govern the IdP, STS, and workload identity pool as one access path, not as separate admin tasks.

Why short-lived token exchange matters more than static service-account keys

Static service-account JSON creates a long-lived credential that can be copied, cached, or reused outside its intended context. Token exchange narrows that exposure by issuing scoped access at runtime and binding it to the authenticated session. For MCP workloads, this reduces the blast radius if configuration files, container layers, or developer environments are exposed. It also gives security teams a cleaner revocation model because identity assertions can expire without waiting for key rotation to catch up.

Practical implication: prefer ephemeral federated credentials over downloadable keys whenever an MCP server touches production data.

How per-user attribution works across the proxy and BigQuery

The proxy does more than pass traffic. It maps the Okta-authenticated user into Google Cloud identity context so BigQuery activity is recorded under a user-level principal rather than under a shared service account. That preserves forensic value, supports least-privilege assignment by user, and makes access reviews meaningful because entitlements can be tied back to named users. This is especially relevant where MCP requests are interactive and data-sensitive, because shared credentials would erase the accountability trail.

Practical implication: ensure audit logs preserve the end-user identity all the way to the data service.

NHI Mgmt Group analysis

Credential sprawl is the real control failure this architecture is designed to eliminate: The article is not really about convenience, it is about replacing a reusable secret boundary with a federated identity boundary. Static service-account keys turn an MCP server into a credential custody problem, while federation keeps the server from becoming a secret store. Practitioners should treat that as a shift in governance model, not just an implementation preference.

Per-user attribution is the difference between controllable access and anonymous machine activity: When BigQuery jobs run under a named Okta user, review, investigation, and entitlement decisions remain anchored to a human account lifecycle. When they run under a shared service account, the access path exists but the accountability path does not. That is the control difference IAM teams should care about.

ToolHive is acting as an identity translation layer, which means the proxy becomes part of the trust boundary: The server, proxy, IdP, and STS are no longer separable in operational terms because each one carries a piece of the authorization story. This is where NHI governance meets workload identity discipline: the trust boundary moves from the application into the federation design, and that boundary needs explicit ownership.

Least privilege is only meaningful if the mapped cloud role reflects the actual data task: The article maps users to BigQuery dataViewer access, which shows the right direction of travel but also the governance requirement. Roles, audiences, and scopes must be scoped to the narrowest working pattern, otherwise federation just replaces one overbroad credential with another. Practitioners should use the architecture to tighten authorization intent, not merely modernize the login path.

Named concept: identity translation layer: This pattern translates a user authenticated in one IdP into a cloud-native workload identity that can reach a specific data service. It is useful because it preserves auditability and short-lived access, but it also means the federation mapping becomes a core governance asset. Teams should manage that mapping with the same discipline they apply to privileged access and workload permissions.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Identity translation layer: MCP federation patterns are moving the control point from local server secrets to the boundary between IdP, proxy, and cloud STS. That means identity teams need to govern mapping, scope, and revocation as a single lifecycle instead of treating them as separate implementation details.

Access reviews will not fix a design that still depends on embedded credentials. If the server can authenticate, exchange, and query without a durable key, then the meaningful control is issuance-time governance, not after-the-fact recertification.

For NHI programmes, the practical lesson is to inventory MCP endpoints alongside service accounts and APIs, because they now sit in the same access plane. A workload that can query BigQuery through federation still needs the same inventory discipline as any other non-human principal.

For practitioners

• Define the federation boundary Document where the Okta session ends, where ToolHive begins, and which Google Cloud principals are created through token exchange. Treat that boundary as a governed identity path with named owners.
• Replace embedded service-account keys Remove JSON credentials from MCP server configs and container images for any production data integration. Use short-lived federated access instead of reusable keys wherever the server queries sensitive cloud data.
• Map cloud roles to user intent Grant each mapped Okta identity only the BigQuery permissions needed for its specific query workload. Review the workforce identity pool mappings and project bindings as part of access governance.
• Preserve end-user attribution in logs Verify that BigQuery activity records the human user, not just the proxy or service wrapper. If logs flatten identity into a shared principal, the federation design is not delivering accountability.
• Review callback and scope settings Check that the redirect URI, authorization server scopes, STS audience, and token exchange scopes align with the intended access path and do not broaden the credential surface unnecessarily.

Key takeaways

• MCP servers that query cloud data should be treated as governed identity workloads, not as applications that happen to need credentials.
• Federated token exchange preserves user attribution and reduces the risk that static keys will outlive the trust relationship they were issued for.
• The most important control shift is from secret storage to identity mapping, scope restriction, and auditable revocation.

Key terms

• Identity Translation: Identity translation is the process of converting one system’s authenticated user context into the format another system can authorise. It is common in federated and multi-service architectures, and failures in translation often look like policy problems even when the root cause is an identity mapping mismatch.
• Workforce identity pool: A cloud identity construct that maps external identities from an organisation's IdP into cloud permissions. It is a federation bridge, not a password store, and it matters because it lets teams assign access to users without issuing long-lived service credentials.
• Federated Short-Lived Credentials: Federated short-lived credentials are temporary access tokens issued through an external identity exchange such as OIDC. They reduce the need for persistent stored secrets and are especially valuable in CI/CD because access expires naturally after the workflow completes.
• Per-user attribution: The ability to trace an action back to the specific identity that initiated it, even when a proxy or server executes the request. This is essential in shared tool environments because it preserves accountability, supports investigation, and prevents shared credentials from hiding the true actor.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.