In MongoDB Atlas, how do database users differ from the users who sign in to the Atlas console?

## Two separate identity planes Atlas is a control plane wrapped around MongoDB deployments, and each half has its own notion of "user". The **control plane** is the Atlas account hierarchy: an *organization* contains *projects* (historically called groups), and people are invited into either with roles like Organization Owner, Project Owner, Project Read Only, or Project Data Access roles. These identities sign in to the Atlas console, are managed through Access Manager, can be grouped into teams, and can be federated to a corporate identity provider. Automation uses the same plane through Atlas Admin API keys or service accounts. What they operate on is infrastructure: creating and scaling clusters, editing the IP access list, configuring backup policies, running restores, setting alerts. The **data plane** is the cluster itself, which speaks the MongoDB wire protocol and knows nothing about Atlas roles. To read or write documents you need a *database user*, created under Database Access. That user is a credential Atlas provisions on every cluster in the project. The most common junior mistake is assuming the first implies the second. A Project Owner who pastes the connection string into `mongosh` and types their Atlas console password gets an authentication failure, because that password is not a database credential. ## Scope of a database user Database users belong to a **project**, not to a cluster and not to an organization. Create one in project *payments-prod* and it exists on every cluster in that project; it does not exist in *payments-staging*. This is one of the strongest arguments for using a project per environment: the project is the boundary for database users, the IP access list, and alert configuration all at once. Atlas can narrow that further. A database user can be restricted to specific clusters or federated database instances in the project, which is how you give an analytics job access to one replica-only cluster without also handing it production. ## Authentication methods - **SCRAM** (username and password) is the default and what most connection strings use. Atlas authenticates these against the `admin` database, which is why the `authSource=admin` semantics are baked into the SRV connection string it hands you. - **X.509** certificates, either with Atlas as the CA or with your own CA, remove the shared password from the connection string. - **AWS IAM** lets an application assume a role on EC2, ECS, EKS, or Lambda and authenticate with temporary STS credentials, so no database password is stored anywhere. - **OIDC workforce and workload identity federation** maps identity-provider groups to database roles, which is how larger organizations avoid minting one Atlas database user per human. Dedicated tiers also support LDAP, but the modern recommendation for human access is federation rather than per-person SCRAM users. ## Roles The roles available are ordinary MongoDB roles plus one Atlas addition: - Per-database: `read`, `readWrite`, `dbAdmin`. - Cluster-wide: `readAnyDatabase`, `readWriteAnyDatabase`, `dbAdminAnyDatabase`, `clusterMonitor`, `backup`. - `atlasAdmin`: Atlas's broad administrative role over the data in the project's clusters. It is a data-plane role — it does not let anyone resize a cluster or change billing — but it is far more than an application needs. You can also define **custom roles** in Atlas, composed of actions and other roles, when the built-ins are too coarse. Atlas deliberately does not expose `root` or internal system roles; the deployment is managed, so a handful of privileged actions stay with the platform. Atlas also supports **temporary users**: a database user marked with an expiry that Atlas deletes automatically. That is the right shape for break-glass or contractor access, because the cleanup is not left to a human's memory. ## What this means in practice Give the application its own database user with the narrowest role that works — usually `readWrite` on one database — and never `atlasAdmin`. Give humans access through federation or short-lived temporary users. Remember that deleting someone's Atlas console account does not revoke any database user they created, and that rotating a database user's password is a data-plane change requiring an application redeploy or a secret-manager refresh, not an Atlas console permission change. Finally, the database user is only half of the gate. Even with perfect credentials, a client whose source address is not on the project's IP access list never gets far enough to authenticate — it sees a connection timeout instead. Authentication and network admission are independent controls in Atlas, and both must pass.