Conceptual Article

Leveraging MongoDB's Built-in Authentication and Authorization Methods

Published on June 29, 2021

Manager, Developer Education

Authorization and authentication are two concepts that are critical for understanding database security. These two concepts are similar, but it’s important to understand what they are and what makes them different. Authentication is the process of confirming whether a user or client is actually who they claim to be. Authorization, on the other hand, involves setting rules for a given user or group of users to define what actions they can perform and which resources they can access.

Authentication

MongoDB features several mechanisms that allow you to authenticate users, with the default mechanism being its Salted Challenge Response Authentication Mechanism (SCRAM). SCRAM involves MongoDB reading and verifying credentials presented by a user against a combination of their username, password, and authentication database, all of which are known by the given MongoDB instance. If any of the user’s credentials don’t match what the Mongo database expects, the database won’t authenticate the user and they won’t gain access until they present the correct username, password, and authentication database.

You can also use a text file to act as a shared password for a group of connected MongoDB instances, such as a replica set or shard cluster. This method, known as keyfile authentication, is considered to be a bare-minimum form of security and is best suited for testing or development environments, as advised by the MongoDB documentation.

For production environments that implement sharding or replication, the MongoDB documentation recommends using another authentication mechanism: x.509 authentication. This involves distributing valid x.509 certificates — either self-signed or obtained from a third-party certificate authority — to the intended cluster members or clients. These are different from keyfiles, though, in that each machine gets its own dedicated x.509 certificate. This means that one machine’s certificate will only be useful for authenticating that machine. A client that presents a stolen x.509 certificate to the database server will not be able to authenticate.

x.509 authentication leverages a concept known as mutual authentication. This means when a client or cluster member authenticates themself to the server, the server is likewise authenticating itself to the client or cluster member. If the client or cluster member attempts to connect to a database server with an invalid x.509 certificate, it will be prevented from doing so since the mutual authentication will fail.

Authorization

MongoDB manages authorization through a computer security concept known as role-based access control. Whenever you create a MongoDB user, you have the option to provide them with one or more roles. A role defines what privileges a user has, including what actions they can perform on a given database, collection, set of collections, or cluster. When you assign a role to a user, that user receives all the privileges of that role.

MongoDB comes with a number of built-in roles that provide commonly-needed privileges. A few of these are available for every database, but most are only available for the admin database, as they’re intended to provide powerful administrative privileges. For example, you can assign a user the readWrite role on any database, meaning that you can read and modify the data held in any database on your system as long as you’ve granted a user the readWrite role over it. However, the readWriteAnyDatabase role — which allows the user to read and modify data on any database except for local and config — is only available in the admin database, as it provides broader system privileges.

In addition to its built-in roles, Mongo also allows you to define custom roles, giving you even more control over what resources users can access on your system. Like users, roles are added in a specific database. Other than roles created in the admin database, which can include privileges to any database in the system, a user-defined role’s privileges only apply to the database in which the role was created. With that said, a role can include one or more existing roles in its definition, and a role can inherit privileges from other roles in the same database.

With such fine-grained control over user privileges, you can set up dedicated users to perform certain functions, like a cluster administrator to manage replica sets and sharded clusters or a user administrator to create and manage users and custom roles. This type of user management strategy can also help harden your system’s security, as it reduces the number of users with broad privileges.

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about our products

Next in series: Encrypting Your MongoDB Data ->

Tutorial Series: MongoDB Security: Best Practices to Keep Your Data Safe

MongoDB, also known as Mongo, is a document database used in many modern web applications. As with any database management system, it’s critical that those responsible for managing a Mongo database adhere to the recommended security best practices, both to prevent data from being lost in the event of a disaster and to keep it out of the hands of malicious actors.

This series of conceptual articles provides a high-level overview of MongoDB’s built-in security features while also highlighting some general database security best practices.

MongoDB Databases Security

Browse Series: 6 articles

About the authors