Authentication

The Authentication tab of the connection dialog sets how the connection signs in. Pick a mode in Authentication Mode:; the fields below change with it.

Set the authentication mode

1. Open the connection dialog (New connection, or Edit on a saved connection).
2. Click the Authentication tab.
3. Choose a mode in Authentication Mode: and fill in its fields (see the sections below).
4. Click Test Connection, then Save.

Modes at a glance

With None the tab warns that anyone who can reach the server can read and change its data. With Legacy it reminds you that SCRAM-SHA-1 is weaker than SCRAM-SHA-256.

For every mode other than None, two options control what the connection tree shows when the user cannot list everything:

• Always show the authentication database of the user account
• Always show all databases and collections defined in roles of the user account

Username and password (SCRAM)

1. Choose Basic (SCRAM-SHA-256).
2. Enter User name: and Password:. The eye button shows or hides the password.
3. Set Authentication DB: if the user is not defined in admin.

Leave Password: empty to be asked at each connect. Once saved, the field shows “Saved (type to replace)” and a checkbox lets you forget the saved password.

X.509 certificates

1. On the SSL tab, tick Use SSL protocol to connect and choose a Client certificate file: (a PEM file with the certificate and its private key). See TLS/SSL.
2. X.509 User: is filled with the certificate’s subject. Keep it unless the server expects another user name.
3. On the Authentication tab, choose X.509. The Open the SSL tab link takes you back to the certificate.

LDAP

Choose LDAP (PLAIN) and enter the directory User name: and Password:. The authentication database is $external. LDAP needs a MongoDB server configured for LDAP (an Enterprise feature). The password travels as plain text inside the connection, so use TLS.

Kerberos (GSSAPI)

1. Choose Kerberos (GSSAPI).
2. Enter the Principal: (for example [email protected]).
3. Change Service name: only if the server does not use mongodb.
4. Set Service realm: when the server’s realm differs from the principal’s (cross-realm trust).
5. Tick Canonicalize host name if your Kerberos setup needs the server’s canonical name.

There is no password field: Kerberos uses the ticket you already hold.

AWS IAM

1. Choose AWS.
2. Either enter AWS access key id: and AWS secret access key: (plus AWS session token: for temporary credentials), or leave the key id empty to use the credentials of the environment: environment variables, the ~/.aws files, SSO or the instance role.

The secret access key is kept in the credential store like a password. The session token is saved with the connection.

The identity confirmation

When the key id is empty, the connection would sign in with this computer’s own AWS identity. A server that is neither MongoDB Atlas nor this computer could misuse that identity. So the first time such a connection opens, an AWS identity box names the servers and asks whether to use your identity with them.

• Use My AWS Identity confirms. The answer is saved with the connection, for those servers only.
• If the servers change later, you are asked again.
• Scheduled tasks, the command line and agents never confirm on your behalf: an unconfirmed connection is refused there.

OpenID Connect (OIDC)

1. Choose MongoDB OIDC.
2. Optionally enter a User name: (sent to the identity provider as a hint).
3. Connect. Your browser opens at the identity provider the server names; sign in there. The browser then returns to a small page served by the application on this computer, and the connection opens.

Tokens stay in memory only and are reused silently for new tabs on the same servers while they are valid; an expired token is renewed without the browser when the provider allows it. Turn off Cache OIDC tokens in Edit > Preferences > Behavior to sign in at every connection. OIDC needs MongoDB 7.0 or later; an older server refuses it with its own message.

Troubleshooting