Guidance for Atlas Authentication
MongoDB Atlas supports a variety of authentication methods to ensure robust security. Atlas requires all users to authenticate to access the Atlas UI, Atlas databases, and the Atlas Administration API.
Note
In this context, a "user" can be a human or an application. We refer to human users as "Workforce Identity" and applications as "Workload Identity".
Two factors determine which authentication types to use:
The identity type (human or machine)
The resource that the identity needs access to. The resource can be one of the following: Atlas UI, Atlas Database, or Atlas APIs.
Recommendations for Atlas Authentication: Single-Region and Multi-Region
Singe-region deployments have no unique considerations for authentication. See the next section for "All Deployment Paradigm Recommendations".
For authentication through the Workforce Identity Federation, use a globally-distributed identity provider.
All Deployment Paradigm Recommendations
The following recommendations apply to all deployment paradigms.
Atlas UI Authentication
Workforce Users
Use IP access restrictions, and then either:
Use Federated Authentication with an SAML 2.0 identity provider, such as Okta, Microsoft Entra ID, or Ping Identity, or
Use Atlas credentials with Multi-factor Authentication (MFA).
Workload Users
This only applies to Workforce users.
Atlas Database Authentication
Workforce Users
Use Workforce Identity Federation.
For development and test environments, you can also use SCRAM. Consider creating temporary database users with just-in-time database access.
Workload Users
Use one of the following:
For development and test environments, you can also use X.509 certificates or SCRAM.
Atlas API Authentication
Note
This applies to both Workforce and Workload users.
Use Service Accounts. For development and test environments, you can also use Service Accounts or API Keys.
Authentication Types
The following sections provide details about the authentication methods used when accessing the Atlas UI, Atlas Database, or the Atlas Administration API.
Federated Authentication
Federated authentication allows you to manage all authentication to the Atlas UI across multiple systems and applications through a central identity provider, which reduces user management complexity. With federated authentication, you can enforce security policies such as password complexity, credential rotation, and MFA within your identity provider's tools.
For the Atlas UI, you can use any SAML compatible identity provider such as Okta, Microsoft Entra ID, or Ping Identity.
Workforce Identity Federation
Workforce Identity Federation allows you to manage all authentication to the Atlas database through your identity provider. To learn more, see Set up Workforce Identity Federation with OIDC.
Workload Identity Federation
Workload Identity Federation enables applications running in cloud environments like Azure and Google Cloud to authenticate with Atlas without the need to manage separate database user credentials. With Workload Identity Federation, you can manage Atlas database users using Azure Managed Identities, Google Service Accounts, or any OAuth 2.0-compliant service. These authentication mechanisms simplify management and enhance security by allowing for passwordless access to the Atlas database.
AWS IAM Role Authentication
You can also authenticate through AWS IAM roles. To learn more, see Set Up Authentication with AWS IAM.
To learn more, see Set up Workload Identity Federation with OAuth 2.0 and Configure Federated Authentication.
Multi-Factor Authentication
For any human user that has access to the Atlas control plane, we recommend MFA for enhanced security. When MFA is enabled, Atlas requires two forms of identification:
The user's credentials
One of the following recommended factors:
Security keys
Biometrics
OTP authenticators
Push notifications
SMS (not recommended as primary factor)
Email (not recommended as primary factor)
Note
If you are using Federated Auth, you configure and manage MFA in the IdP. If you are using Atlas credentials, MFA is configured and managed within Atlas. MFA is required when using Atlas credentials.
To learn more, see Manage Your Multi-Factor Authentication Options.
X.509 Client Certificates
X.509 certificates provide the security of mutual TLS, making them suitable for staging and production environments, and you can bring your own certificate authority for use with X.509. The disadvantage of X.509 is that you must manage certificates and the security of these certificates on the application side, while Workload Identity Federation allows for password-less access and easier application security.
To learn more, see X.509.
SCRAM Password Authentication
Atlas clusters support SCRAM password authentication for user authentication, but we recommend SCRAM only for use in development and test environments.
If you leverage X.509 or SCRAM authentication, we recommend that you use a third-party secrets manager like HashiCorp Vault or AWS Secrets Manager to generate and store complex database credentials.
To learn more, see SCRAM.
Service Accounts
Service accounts use industry-standard OAuth2.0 to securely authenticate with Atlas through the Atlas Administration API. We recommend that you use service accounts instead of API keys when possible because they provide added security through use short-lived access tokens and required credential rotations.
You can manage programmatic access for service accounts only by using the Atlas UI or the Atlas Administration API. You can't manage programmatic access for service accounts through the Atlas CLI or Terraform.
To learn more, see Service Accounts Overview.
API Keys
Service accounts are the preferred method of authentication. Atlas provides legacy support for API key-based authentication for managing programmatic access. API key-based authentication uses HTTP Digest authentication to protect requests. To learn more, see Atlas Administration API Authentication.
Secrets Management
We recommend using a third-party secrets manager like HashiCorp Vault or AWS Secrets Manager to generate and store complex database credentials. A secrets manager can generate database credentials dynamically based on configured roles for Atlas databases.
To learn more, see the blog Manage MongoDB Atlas Database Secrets in HashiCorp Vault.
Deployments
To learn our recommendations for deployments that relate to authentication, see Guidance for Atlas Orgs, Projects, and Clusters.