> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# 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:**

The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see [Shared Responsibility Model.](https://www.mongodb.com/resources/products/fundamentals/shared-responsibility)

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

## Atlas UI Authentication

- Workforce Users

  Use IP access restrictions, and then:

  - Use [Federated Authentication](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-federated_auth) with an SAML 2.0 identity provider, such as Okta, Microsoft Entra ID, or Ping Identity, **and**

  - Use Atlas credentials with [Multi-factor Authentication (MFA)](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-mfa). You should always use the most secure form of MFA available, such as a hardware key or biometrics.

- Workload Users

  This only applies to Workforce users.

## Atlas Database Authentication

- Workforce Users

  Use [Workforce Identity Federation.](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-workforce_if)

  For development and test environments, you can also use [SCRAM](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-scram). Consider [creating temporary database users](https://www.mongodb.com/docs/atlas/architecture/current/auth/authorization.md#std-label-arch-center-just-in-time) with just-in-time database access.

- Workload Users

  Use one of the following:

  - [Workload Identity Federation](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-workload_if)

  - [AWS-IAM authentication](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-iam)

  - [X.509](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-x509) certificates

  For development and test environments, you can also use [X.509](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-x509) certificates or [SCRAM.](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-scram)

## Atlas API Authentication

**Note:**

This applies to both Workforce and Workload users.

Use [Service Accounts](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-admin-service-accounts). For development and test environments, you can also use [Service Accounts](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-admin-service-accounts) or [API Keys.](https://www.mongodb.com/docs/atlas/architecture/current/auth/authentication.md#std-label-arch-center-admin-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 (Multi-Factor Authentication) within your identity provider's tools.

For the Atlas UI, you can use any SAML (Security Assertion
Markup Language) 2.0 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.](https://www.mongodb.com/docs/atlas/workforce-oidc.md#std-label-oidc-authentication-workforce)

#### Workload Identity Federation

Workload Identity Federation enables applications running in cloud environments like Azure (Microsoft 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 (Microsoft 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 (Amazon Web Services) IAM (Identity and Access Management) roles. To learn more, see [AWS IAM Authentication.](https://www.mongodb.com/docs/atlas/security/aws-iam-authentication.md#std-label-set-up-pwdless-auth)

To learn more, see [Set up Workload Identity Federation with OAuth 2.0](https://www.mongodb.com/docs/atlas/workload-oidc.md#std-label-oidc-authentication-workload) and [Configure Federated Authentication.](https://www.mongodb.com/docs/atlas/security/federated-authentication.md#std-label-atlas-federated-authentication)

### Multi-Factor Authentication

For any human user that has access to the Atlas control plane, we **require** MFA (Multi-Factor Authentication) for enhanced security. Atlas supports the following MFA methods as secondary identification:

- Security keys

- Biometrics

- OTP authenticators

- Push notifications with Okta Verify

- Email

**Note:**

If you are using Federated Auth, you configure and manage MFA in the IdP (Identity Provider). 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.](https://www.mongodb.com/docs/atlas/security-multi-factor-authentication.md#std-label-atlas-enable-mfa)

### 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.](https://www.mongodb.com/docs/manual/core/security-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](https://developer.hashicorp.com/vault/docs/secrets/databases/mongodbatlas) or AWS (Amazon Web Services) Secrets Manager to generate and store complex database credentials.

To learn more, see [SCRAM.](https://www.mongodb.com/docs/manual/core/security-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 (Application Programming Interface) keys when possible because they provide added security through short-lived access tokens and required credential rotations.

You can manage programmatic access for service accounts by using the Atlas UI, Atlas CLI, Atlas Administration API, and Terraform.

### API Keys

Service accounts are the preferred method of authentication. Atlas provides legacy support for API (Application Programming Interface) key-based authentication for managing programmatic access. API (Application Programming Interface) key-based authentication uses HTTP (HyperText Transport Protocol) Digest authentication to protect requests.

To further enhance security and minimize the risk of unauthorized access:

- Follow best practices for rotating API keys regularly. To learn how to rotate these keys with [HashiCorp Vault](https://www.vaultproject.io/), for example, see the [Hashicorp documentation.](https://developer.hashicorp.com/vault/docs/secrets/mongodbatlas)

- Use the IP access list for your API keys. To learn more, see [Require an IP Access List for the Atlas Administration API.](https://www.mongodb.com/docs/atlas/configure-api-access/#optional--require-an-ip-access-list-for-the-atlas-administration-api)

To learn more, see [Atlas Administration API Authentication Methods.](https://www.mongodb.com/docs/atlas/api/api-authentication.md#std-label-api-authentication)

### Secrets Management

We recommend using a third-party secrets manager like [HashiCorp Vault](https://developer.hashicorp.com/vault/docs/secrets/databases/mongodbatlas) or AWS (Amazon Web Services) 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.](https://www.mongodb.com/blog/post/manage-atlas-database-secrets-hashicorp-vault?tck=docs)

### Deployments

To learn our recommendations for deployments that relate to authentication, see [Guidance for Atlas Orgs, Projects, and Clusters.](https://www.mongodb.com/docs/atlas/architecture/current/hierarchy.md#std-label-arch-center-hierarchy)

## Additional Security Measures

To further enhance security and minimize the risk of unauthorized access, consider these additional security measures:

- [Rotate service account secrets](https://www.mongodb.com/docs/atlas/tutorial/rotate-service-account-secrets/#std-label-rotate-service-account-secrets) before they expire.

- Use an [IP access list](https://www.mongodb.com/docs/atlas/configure-api-access/#optional--require-an-ip-access-list-for-the-atlas-administration-api) for your service accounts.

- Assign the least privileged [Atlas role](https://www.mongodb.com/docs/atlas/reference/user-roles/) required for the service account's intended purpose to adhere to the principle of least privilege.

To learn more, see [Service Accounts Overview.](https://www.mongodb.com/docs/atlas/api/api-authentication/)