Okta-authenticated BigQuery MCP access: what changes for IAM teams

TL;DR: An Okta-to-Google Cloud federation flow for BigQuery-accessing MCP servers can avoid embedded service-account keys, preserve user attribution, and use short-lived token exchange instead of static JSON credentials, according to Stacklok. The deeper issue is not just convenience: it is replacing brittle secret handling with governed, auditable identity boundaries that IAM and NHI teams can actually control.

NHIMG editorial — based on content published by Stacklok: Okta authentication for BigQuery MCP servers

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.

Questions worth separating out

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.

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.

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

A: A single shared credential breaks attribution, scope control, and revocation precision.

Practitioner guidance

• 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.
• 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.

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

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

Okta-authenticated BigQuery MCP access: what changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →