Workforce and Workload Identity Federation
Parent: MongoDB Ops Manager and Cloud Manager · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-511384aadb70
↓ Facts as markdownall context files
Source-anchored research for Workforce and Workload Identity Federation. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- OIDC Core defines an ID token as a JWT describing authentication and requires issuer, subject, audience, and expiration claims. Google service-account ID tokens use those fields, but this general token structure is not proof of support for every Atlas login flow. (high confidence) [source]
How it works
- Users reported that Google as a human OIDC provider failed because client_secret was missing. An August 6, 2025 feedback comment described planned optional client-secret support. This is historical compatibility evidence, not proof that Google workforce login remains unsupported in October 2026. (medium confidence) (verified as of 2025-08-06) [source]
- Workforce federation requires JWT tokens and rejects opaque access tokens. Google documents ordinary user access tokens as opaque; generic OIDC compatibility therefore does not establish that a Google human-login flow satisfies Atlas workforce requirements. (high confidence) (verified as of 2026-10-23) [source]
- MongoDB recommends Authorization Code Flow with PKCE for workforce users; Device Authorization Flow is an option for machines without a browser. Register a public native client with redirect URI http://localhost:27097/redirect. (low confidence) (verified as of 2026-10-23) [source]
Comparisons and alternatives
- Workforce setup requires a public/native OIDC application, JWT tokens rather than opaque tokens, and user or group mappings to database privileges. MongoDB recommends Authorization Code with PKCE; Device Authorization is the alternative for machines without browsers. (low confidence) [source]
- For the Google service-account path, register the numeric service-account Unique Id as the federated database user identifier, rather than the service-account email; the token subject identifies that account. (high confidence) [source]
Facts and statements
- Atlas distinguishes Workforce Identity Federation for human database users using OIDC from Workload Identity Federation for applications using external programmatic identities, including GCP service accounts. (high confidence) (verified as of 2026-10-23) [source]
- The cached Atlas setup guides restrict both federation paths to dedicated clusters (M10 and above) running MongoDB 7.0.11 or later; this is narrower than generic references to MongoDB 7.0 support. (high confidence) (verified as of 2026-10-14) [source]
- Workload federation lets a supported driver obtain a token for the runtime identity and present it to Atlas without a database password. Atlas still stores the identity-to-privilege mapping; federation does not remove database authorization configuration. (high confidence) [source]
- For GCP metadata-service authentication, configure MONGODB-OIDC with ENVIRONMENT=gcp and TOKEN_RESOURCE set to the configured audience. PyMongo documents built-in support for Compute Engine or another runtime that exposes the GCP metadata service. (high confidence) (verified as of 2026-10-23) [source]
- On the MongoDB Go driver’s master branch, client-option validation for MONGODB-OIDC rejects a nonempty password and simultaneous human and machine callbacks. If ENVIRONMENT is “gcp,” it requires a nonempty TOKEN_RESOURCE. These validation errors can occur before server authentication. (low confidence) (verified as of 2026-10-22) [source]
- Google recommends avoiding service-account keys where possible, attaching an account to an eligible runtime or using federation for an external workload. Together with the Atlas metadata-token path, this supports avoiding downloaded service-account keys as database application credentials. (medium confidence) [source]
- Google Cloud incoming Workload Identity Federation and Atlas database federation are separate trust configurations. GitHub documents exchanging a GitHub OIDC token to access Google Cloud; Atlas requires its own identity provider and database privilege mapping. Configuring the former alone does not configure Atlas access. (medium confidence) [source]
- For a GCP application connection, verify the audience and registered numeric identity as well as network reachability. Successful federation configuration does not itself establish a route or grant database roles. (medium confidence) [source]
- For workforce access, Atlas documents mongosh and Compass; workload federation uses supported drivers and excludes those two tools. (high confidence) (verified as of 2026-10-23) [source]
- For GCP workloads, configure the Atlas issuer as https://accounts.google.com, keep the user claim as sub, and map the database identity to the service account Unique ID. Google identifies the same issuer and subject fields in service-account ID tokens. (high confidence) (verified as of 2026-10-23) [source]
- Atlas offers built-in metadata authentication and application-provided token callbacks. The callback must obtain a suitable token; federation does not remove the need to configure identity trust and database privileges. (high confidence) (verified as of 2026-10-23) [source]
- An Atlas workload provider becomes available across projects in its connected organization, but administrators must still add federated database identities and assign privileges. (low confidence) (verified as of 2026-10-23) [source]
- Atlas lists Compute Engine, App Engine, Cloud Functions, Cloud Run, GKE, and Cloud Build as GCP infrastructure supporting built-in workload authentication. Check the chosen driver and runtime before deployment. (low confidence) (verified as of 2026-10-23) [source]
- Google Cloud IAM Workload Identity Federation exchanges external credentials for access to Google Cloud resources. Atlas workload federation instead authenticates applications to MongoDB. Treat these as separate trust configurations; a Google IAM pool alone does not establish Atlas database access. (high confidence) (verified as of 2026-10-23) [source]
- Google distinguishes opaque OAuth access tokens from Google-signed service-account ID tokens. Although the Atlas overview uses the term access token broadly, GCP integrations must select the token format, issuer, audience, and subject expected by their configured Atlas provider. (medium confidence) (verified as of 2026-10-23) [source]
Children
- GCP metadata-service JWT authentication (frontier)
- OIDC audience and subject mapping (frontier)
- Federated database role assignment (frontier)
Frontier under this node: Federated database role assignment, GCP metadata-service JWT authentication, OIDC audience and subject mapping