In an era where data breaches make headlines, master and authentication is your first line of defense in securing your MongoDB deployments. MongoDB offers numerous options to safeguard your data. In this lesson, we'll explore authentication in MongoDB and what a database user is. Next, we'll examine various authentication methods available in MongoDB. Finally, we'll enable authentication for a self managed deployment. To interact with MongoDB deployments, users have to authenticate their identity. A database user in MongoDB functions as a unique credential used to access your database, defining specific permissions and dictating what actions can be performed within the database. This authentication process is crucial as it ensures that only authorized users have access to specific data and operations, keeping our database secure and efficient. MongoDB offers several robust authentication methods tailored to suit different needs and environments. These include SCRAM, SALTED Challenge Response Authentication mechanism, Identity Federation, X.509 certificates, and Kerberos. Each method has unique features and advantages, providing flexibility and security in various scenarios. Let's explore these options in greater detail to help you make an informed decision on which best suits your needs. SCRAM is a simple username and password setup. It's ideal for dev environments where you need to move quickly. SCRAM is not recommended for production applications because this method is less secure than the others. Even if you're only using SCRAM and DEV, it's still important to securely manage these credentials. We recommend using strong passwords and a secure secrets manager like HashiCorp's Vault. Next, let's explore identity federation. Identity federation for database users involves integrating with your organization's existing identity provider through OIDC OAuth 2.0 standards. When it comes to identity federation in MongoDB, it can be applied to both workforce and workload users. These users serve different purposes based on their roles and requirements. Let's take a closer look at what these terms mean. Starting with workforce users. These are the human users who access and manage MongoDB through interfaces like the Compass or Command Line tools. By using identity federation, these users can authenticate with the credentials handled by your organization's identity provider such as Okta or Microsoft Entra ID. On the other hand, we have workload users which refer to non human users, often applications or services that need to interact with MongoDB programmatically. Typically, this interaction involves API keys or service accounts establishing trust and managing access rights efficiently. There are options for each cloud provider that you might use with your self managed deployment. Azure users can take advantage of Azure service principles and managed identities to secure their deployments. On Google Cloud, you can leverage Google service accounts. And for those working with AWS, use AWS identity and access management, IAM, roles. These allow you to securely authenticate and authorize application access to your self managed MongoDB deployments. Since you can manage both your workforce and workload users through your organization's identity provider, you can keep everything centralized. This makes it straightforward to handle all user access from one place. Next up, database users can use x five zero nine certificates to authenticate themselves. By using X.509 certificates, we take advantage of mutual TLS. Mutual TLS builds upon the standard TLS handshake by requiring both the client and the server to authenticate each other's certificate. This mutual authentication ensures that both parties involved in a communication are trusted. X.509 is ideal for authenticating applications that need to connect to your clusters. In addition, X.509 certificates are used for internal authentication between nodes in your cluster. When generating X.509 certificates, you'll need to get them signed by a certificate authority. For this, you have the option to use your own certificate authority or one of the many trusted ones. After that, we have Kerberos, which is a network authentication protocol that uses secret key cryptography and a trusted third party to authenticate client server applications. It provides single sign on capability, allowing a user to authenticate once and gain access to multiple services without reauthenticating. Lastly, we have lightweight directory access protocol or LDAP for short. LDAP is a protocol used for accessing and maintaining distributed directory information services over a network. As of MongoDB 8.0, LDAP is being deprecated. That being said, it will continue to be available and operate for the lifetime of MongoDB 8.x, giving organizations ample time to migrate off of it. For more information on migrating off of LDAP, you can check out the MongoDB documentation. As you can see, MongoDB offers a variety of robust authentication solutions. Choosing the right one often depends on your organization's specific security requirements. Now, let's shift our attention to enabling authentication for a self managed deployment. Here, we'll use SCRAM to enable authentication so it's easy for you to demo. Keep in mind that we only recommend using SCRAM for dev environments and not for production. For more sophisticated authentication methods, check out the MongoDB docs. To do this, we open up the mongod.conf file for your deployment. Next, we enable security dot authorization. After that, we have to reset our node so the changes can go into effect. Okay. Now that we have SCRAM enabled, let's create a user and test it out. We need to connect our cluster, but SCRAM is enabled. But we can still connect since we can take advantage of the local host exception. This allows us to connect without a username and password from local host, which is running our cluster. Once connected, switch to the admin database. This database will serve as the authentication database for our new user. While authentication occurs here, the user can still access other databases. The authentication database in MongoDB serves as the default location where user credentials are stored and verified. Next, we use the create user method on the DB and pass in our user configuration. Inside the user configuration, we provide a username and password. I'm using the password prompt, so I don't provide the password in plain text. Finally, we provide a list of roles. We'll cover these more in-depth later. After running the command, we should get confirmation that our user was created. Now let's authenticate with the new user. We'll need to update our connection string to include the username and the authentication database. After running it, we'll be prompted to enter a password. Once we enter the correct password, we should successfully connect to our cluster. Great work. Before we move on, let's take a moment to quickly recap what we learned. First, we learned that authentication in MongoDB ensures only authorized users gain access, keeping our database secure and efficient. We also learned that a database user is a unique credential used to access your cluster. After that, we covered the many different authentication options in MongoDB and their various use cases. Choosing the right method depends on your specific security needs, helping you safeguard your MongoDB deployment. Finally, we enabled SCRAM authentication and created a new database user to test it out.