Okta federation for BigQuery MCP servers reduces credential sprawl

At a glance

What this is: This is a hands-on federation pattern for letting an MCP server query BigQuery through Okta-authenticated user identity instead of embedded Google service-account keys.

Why it matters: It matters because IAM teams need governed, auditable access paths for non-human workloads and agent-facing tools without creating long-lived secrets or losing user attribution.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Stacklok's blog on Okta authentication for BigQuery MCP servers

Context

MCP server authentication becomes an identity governance problem the moment the server needs to reach enterprise data sources. In this case, the issue is not just whether the tool can connect to BigQuery, but whether that connection is mediated through accountable identity, short-lived tokens, and policy boundaries instead of static credentials.

Stacklok's example uses Okta federation and Google Cloud token exchange to avoid service-account keys and preserve per-user attribution. That is a familiar pattern for IAM teams, but it becomes more important when MCP servers sit between users and sensitive data because the server must not become a secret-keeping middleman.

The relevant question for practitioners is whether the access path can survive audit, offboarding, and scope reduction without depending on embedded JSON credentials or manual handling. For broader NHI governance context, see the Ultimate Guide to NHIs and the Guide to the Secret Sprawl Challenge.

Key questions

Q: How should security teams avoid service-account sprawl in MCP server deployments?

A: Use federation and token exchange so the MCP server does not store reusable cloud keys. The access path should rely on short-lived tokens, explicit audience mapping, and scoped cloud roles, with the IdP acting as the source of user identity and the cloud provider enforcing authorisation.

Q: Why do federated MCP workflows improve auditability?

A: They preserve the link between the human user, the authenticated session, and the cloud action taken by the server. That means query logs can show who initiated the request, which is far more useful than shared service-account activity when you are investigating misuse or reviewing access.

Q: What breaks when MCP servers rely on a single shared credential?

A: A single shared credential breaks attribution, scope control, and revocation precision. If the server can be used by multiple people, you cannot easily tell which human authorised a specific action, and removing the credential can disrupt unrelated workflows. That makes the credential both operationally convenient and governance-heavy.

Q: What should IAM teams review before allowing MCP in production?

A: IAM teams should review how the protocol establishes identity, how tool permissions are assigned, and whether the same policy is enforced consistently across clients. If the answer differs by implementation, the organisation has a governance gap that can produce uneven access and weak audit trails.

Technical breakdown

OIDC federation for MCP server access

The flow uses OpenID Connect to authenticate the user through Okta, then exchanges that identity for Google Cloud access through a workforce identity pool. The MCP server itself does not hold a Google service-account key. Instead, the proxy mediates between the user session and the cloud provider, so access is derived from the authenticated subject and the mapped claims. This reduces credential persistence and makes the trust boundary explicit: identity is asserted by the IdP, translated by STS, and consumed by the workload. The important mechanism is not the MCP server alone, but the chain of federation that keeps the server out of direct secret custody.

Practical implication: Design MCP access paths so the server never needs reusable cloud keys.

Why token exchange matters more than static secrets

Token exchange turns a user-authenticated session into a short-lived cloud token with defined scopes. That is materially different from embedding a JSON service-account credential in configuration, because the token can be audience-bound, time-bound, and tied to a specific principal. In NHI terms, the access artifact is ephemeral, but governance still depends on scope, auditability, and revocation. This pattern also separates authentication from authorisation: Okta proves who the user is, while Google Cloud decides what that identity may do. For MCP deployments, that separation is the control plane, not an implementation detail.

Practical implication: Use token exchange when you need scoped access without storing long-lived credentials.

User attribution and least privilege in federated MCP workflows

The architecture preserves per-user attribution by mapping the Okta identity into Google Cloud permissions, so BigQuery actions can be traced back to a person rather than a shared service account. That matters because shared credentials collapse accountability, especially in multi-user MCP environments where several clients may invoke the same server. Least privilege is enforced by binding specific users or groups to BigQuery roles, which limits blast radius when an account is misused. The practical value is not just cleaner logs. It is a governance model that aligns identity proof, entitlements, and activity records across IdP and cloud.

Practical implication: Map each user or group to the narrowest BigQuery role that supports the task.

NHI Mgmt Group analysis

Static cloud credentials are the wrong trust primitive for MCP server access. This pattern shows why service-account keys do not belong in an MCP configuration file when the server is brokering user-driven data access. Once a credential is embedded, every runtime path that can reach the file can potentially reuse it, which turns a federation problem into a secret sprawl problem. Practitioners should treat embedded cloud keys as a governance failure, not a convenience trade-off.

Per-user federation restores accountability that shared NHI credentials erase. BigQuery access tied to a federated Okta identity preserves the audit trail from user to query to dataset. That is a different control model from shared service accounts, where the workload is visible but the human intent behind the action disappears. The practical conclusion is that MCP deployments should be designed so the identity doing the work is the identity you can govern and review.

Ephemeral token exchange is a lifecycle control, not just an authentication feature. Short-lived access only helps if it is paired with scoped roles, revocation paths, and offboarding logic that can follow the identity across the IdP and the cloud provider. Otherwise, the organisation still accumulates latent access even if the initial login is federated. For identity teams, this is a reminder that lifecycle governance applies equally to human users, service access, and tool-facing workflows.

BigQuery access mediation belongs in the proxy, not inside the MCP server. Separating auth, token exchange, and routing from the tool execution layer keeps the server focused on data operations while the proxy enforces identity boundaries. That architectural split also gives security teams a clearer place to instrument, log, and revoke access. The practitioner implication is simple: if the server is also your trust boundary, you have already lost control of the identity plane.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• That is why the Guide to the Secret Sprawl Challenge is a useful next read for teams designing federated access patterns.

What this signals

Secret-free federation is becoming the baseline expectation for machine-access workflows. As MCP servers move from local demos into production-connected tools, the old pattern of embedding cloud credentials in configuration will create more governance debt than speed. IAM teams should assume that every persistent secret in a tool chain will eventually become an audit, revocation, or exfiltration problem.

Per-user identity mapping will matter more than server identity branding. The control question is not which tool framework you use, but whether the request can be traced to a real user, a scoped entitlement, and a revocable trust chain. That is the same accountability model that separates governed NHI use from uncontrolled shared access.

Identity blast radius is the right concept for MCP adoption. When a single proxy or token exchange layer sits between users and cloud data, the risk is no longer just access. It is how much data, how many identities, and how many downstream systems inherit the same trust decision when that layer is misconfigured.

For practitioners

• Remove embedded service-account keys from MCP server configs Replace JSON credentials and other reusable Google Cloud keys with federated token exchange through a proxy or equivalent trust broker. Keep the workload from ever becoming a static secret custodian.
• Map user identity to cloud permissions explicitly Bind Okta identities or groups to the narrowest BigQuery roles needed for the workload, and preserve the subject mapping in logs so query activity remains attributable to the real user.
• Separate authentication from tool execution Run the MCP server as the tool layer and place authentication, callback handling, and STS exchange in a dedicated proxy so the access boundary is visible and enforceable.
• Review revocation and offboarding paths for federated access Test what happens when a user leaves, a group changes, or the IdP claim mapping changes, and confirm that cloud access disappears without waiting for manual cleanup.

Key takeaways

• MCP server access to cloud data should be treated as an identity governance problem, not just an integration task.
• Federated, short-lived tokens preserve attribution and reduce secret sprawl, but only if roles and revocation are tightly scoped.
• IAM teams should design MCP deployments so the tool never needs reusable cloud credentials in the first place.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• 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.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
• 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.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Okta OIDC application and authorization-server configuration for MCP federation
• Exact Google Cloud workforce identity pool and audience-mapping setup for per-user BigQuery access
• Full ToolHive proxy command-line flags and callback settings for the remote-auth flow
• Client-side MCP registration details for Claude Code and other MCP-compatible tools

👉 Stacklok's full post covers the end-to-end federation flow, proxy flags, and client setup details

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 building or maturing an identity security programme, it is worth exploring.