Meccanismi di autenticazione: SCRAM e x.509

By default, a freshly installed MongoDB instance listens on 0.0.0.0:27017 with no authentication required. Countless real-world breaches have resulted from developers leaving MongoDB exposed to the internet without auth enabled. Production deployments must always enable authentication so that only credentialed users and services can connect. MongoDB supports multiple authentication mechanisms — the two most important are SCRAM and x.509 certificates.

Authentication is enabled by adding security.authorization: enabled to the mongod.conf configuration file (or passing --auth on the command line). Once enabled, every connection attempt must supply valid credentials. Before enabling auth on an existing deployment, always create an admin user first — otherwise you will lock yourself out.

Connect to MongoDB without auth while it is still in unauthenticated mode (or in localhost exception mode) to create the first user. Grant them the userAdminAnyDatabase role so they can create additional users. Then enable --auth and reconnect with credentials. The localhost exception allows an unauthenticated localhost connection only until the first user is created.

SCRAM (Salted Challenge Response Authentication Mechanism) is MongoDB's default password-based authentication protocol. MongoDB uses SCRAM-SHA-256 (the newer, stronger variant) by default. SCRAM avoids sending the actual password over the network — the client and server perform a cryptographic handshake using salted hashes. Clients automatically negotiate the strongest SCRAM variant the server supports.

Each application service should have its own MongoDB user with only the permissions it needs. A read-only reporting service should only have the read role on the specific database. A write-heavy API should only have readWrite. Granting root or dbOwner to application accounts violates the principle of least privilege and amplifies breach impact.

x.509 certificates provide stronger authentication than passwords by using cryptographic key pairs. A client presents a certificate signed by a trusted Certificate Authority (CA) instead of a username/password. MongoDB maps the certificate's Subject Distinguished Name (DN) to a MongoDB user. This is the preferred mechanism for internal cluster member authentication (replicaset nodes authenticating with each other).

To enable x.509, you must configure TLS (the underlying transport) and set security.clusterAuthMode: x509 for intra-cluster auth. For client auth, set net.tls.CAFile to your CA certificate so MongoDB can verify client certificates. This requires generating a CA, signing certificates for each member and client, and distributing them securely.

When using x.509 client authentication, the MongoDB username must exactly match the Subject DN of the client certificate. Create the user in the $external database (not the regular admin or app database) since credentials are validated externally by the certificate, not by MongoDB's internal credential store.

SCRAM is simpler to set up — create a user with username/password and connect. It is suitable for most application services and developer access. x.509 is more complex (requires PKI infrastructure) but provides stronger guarantees: no passwords to rotate or leak, certificate revocation lists (CRLs) for immediate access revocation, and is mandatory for replica set member authentication in high-security environments.

MongoDB provides db.updateUser() to change an existing user's password without dropping and recreating the account. In Atlas, rotate credentials through the Atlas UI or API. When rotating, update your application's connection string before changing the password to avoid a window of broken connectivity. Use connection string URI environment variables so password rotation requires only an env update and application restart.

Audit your MongoDB users regularly. Use db.getUsers() to list all users in a database and db.getUser('name') for details on a specific account, including their assigned roles. Remove stale or compromised accounts immediately with db.dropUser(). On Atlas, the Users section of the Database Access panel provides a central inventory of all users across all clusters.

In this lesson you learned: SCRAM-SHA-256 is MongoDB's default password-based auth mechanism and suitable for most application use cases, x.509 certificates provide stronger cryptographic authentication and are preferred for cluster-member internal auth, and always create users with least-privilege roles — application accounts should never hold admin-level permissions. Next up we dive into Role-Based Access Control.