In an error where data breaches make headlines, mastering authentication is your first line of defense in securing your MongoDB Atlas deployments. Atlas offers numerous options to safeguard your data. In this lesson, we'll explore authentication within Atlas, distinguish between Atlas users and database users, and investigate the various methods available for authentication for both types of users. To interact with Atlas database services, users have to authenticate their identity. Whether it's through simple username password combinations or advanced federated authentication, Atlas ensures that your database access is secure and reliable. Understanding the rules within MongoDB Atlas is crucial for effective management and security. Let's begin by focusing on two core components, the control plane and the data plane. Within Atlas, the control plane is the administrative layer responsible for managing your Atlas environment. This includes setting up and configuring clusters, managing organizational settings, and implementing security protocols. Atlas users handle these tasks. By keeping the control plane distinct from the data plane, Atlas allows for a structured and secure way to administer your overall database environment. The data plane, on the other hand, is the layer focused on accessing and interacting with data, databases, collections, and documents stored in Atlas clusters. Database users oversee management of the data plane. By defining the data plane separately, database users can have focused permissions that grant them necessary access to perform their roles. Together, these planes create a comprehensive system where you have clear boundaries of responsibility and access, ensuring security and operational efficiency within MongoDB Atlas. Given this, there are different authentication methods for the control plane and data plane. For Atlas users, authentication can be accomplished with a username and password paired with multi factor authentication for added security. Alternatively, you can leverage single sign on to integrate with popular platforms like GitHub or Google. Often, your organization requires a more integrated approach. For this, you can set up federated authentication. This allows you to connect with your preferred identity provider such as Okta or Microsoft Entra ID to ensure seamless access for your team. For a full list of supported identity providers, make sure you check out the Atlas documentation. But what about programmatic access to Atlas? You have the option to use API keys or create service accounts for accessing the Atlas administration API. While API keys are the legacy method, service accounts offer significant advantages. They leverage industry standard OAuth 2.0, authenticate via short lived access tokens, and allow you to regularly rotate the service account's client secret. Both approaches provide secure access, enabling you to automate various processes while maintaining robust security. Next, let's turn our attention to the database user authentication methods available in Atlas. We have several options, each offering its own advantages and potential drawbacks. These include SCRAM, SALTED Challenge Response Authentication mechanism, Federated Authentication, and X.509 certificates. 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 in dev, it's still important to securely manage these credentials. We recommend using strong passwords and a secure secrets manager like HashiCorp Vault. Next, let's explore identity federation. Much like the federated authentication for Atlas users, identity federation for database users involves integrating with your organization's existing identity provider. To set up Identity Federation, you'll need to go to the Federation Management Console within Atlas and complete the following steps in order. Add and verify your domains. Configure your identity provider with Atlas. Connect your domains with your identity provider, and activate your identity provider. You can find detailed guides for each identity provider in the Atlas documentation. When it comes to identity federation in Atlas, it can be applied to both workforce and workload users, serving 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 Atlas through interfaces like the web UI 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 nonhuman users, often applications or services that need to interact with MongoDB Atlas programmatically. Typically, this interaction involves API keys or service accounts, establishing trust and managing access rights efficiently. Workload identity federation can be configured for identities from each cloud provider or any OAuth 2.0 compliant authorization service. Azure users can use Azure service principles and managed identities to secure workload users. On Google Cloud, you can leverage Google service accounts. And for those working with AWS, use AWS IAM roles. These allow you to securely authenticate and authorize application access to your MongoDB Atlas deployments. Workforce and Workload Identity Federation is ideal for centrally managing user and workload access via your organization's identity provider. This means you can keep everything centralized, making it straightforward to handle all your organization's user access from one place. Next up, database users can use X.509 certificates to authenticate themselves. By using X.509 certificates, we can 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. 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. 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 Atlas documentation. As you can see, Atlas offers a variety of robust authentication solutions. Choosing the right one often depends on your organization's specific security requirements. Before we move on, let's take a moment to quickly recap what we learned. First, we learned that the control plane is responsible for managing your Atlas environment. Second, the data plane is focused on accessing and interacting with the data stored within Atlas clusters. Next, we learned that the Atlas user is responsible for the control plane, while the database user is responsible for the data plane. Given this, Atlas users and database users are separate identity types with their own authentication methods. Finally, we covered the many different authentication methods for both Atlas and database users.