Overview
MongoDB Atlas App Connections lets third-party applications act on behalf of Atlas users through user-delegated access. As an organization owner, you control whether applications can connect to your organization.
This page describes how to:
Enable or disable third-party app connections for your organization.
Set the maximum refresh token lifetime for authorized applications.
View the applications that users have authorized.
Understand what cleanup remains your responsibility when you disable an application's access.
How Delegated Access Works
When a user authorizes an application, the application acts on behalf of that user. The application receives tokens that let it call the Atlas Administration API with the same permissions the user holds in their Atlas organizations and projects. If the user cannot perform an action, the application cannot perform it on their behalf either.
Because access is delegated from the user's own permissions:
The application's effective permissions change automatically when the user's roles change.
Operations against your organization succeed only when your organization allows third-party app connections and the authorizing user holds the required role for the operation.
Applications use the OAuth 2.1 Authorization Code flow with Proof Key for Code Exchange (PKCE) to obtain delegated access. To learn how applications integrate with this flow, see Integrate Your App with Atlas App Connections.
Enable or Disable Third-Party App Connections
Whether third-party app connections are enabled by default depends on when your organization was created:
Existing organizations, and organizations created before Atlas App Connections launched, have third-party app connections disabled by default. An organization owner must enable them.
New organizations that a user creates when they sign up for Atlas after Atlas App Connections launched have third-party app connections enabled by default. This does not apply to users who join an existing organization.
While third-party app connections are disabled, any delegated access token that an application obtains receives a 403 Forbidden response when it calls the Atlas Administration API for your organization.
When you disable third-party app connections for an organization that previously allowed them, the change takes effect immediately: Atlas Administration API calls that target your organization through user delegation begin returning 403 Forbidden.
Disabling third-party app connections stops applications from accessing the control plane through user delegation. It does not revoke other access an application might already have:
Data plane access continues. Database users and connection strings that an application created keep working, so existing MongoDB driver or connection-pool sessions remain active.
Other control plane credentials continue. If an application created service accounts or API keys, those retain control plane access until you remove them.
To fully remove an application's access, you must clean up these resources yourself. See Limitations and Responsibilities.
To allow or restrict third-party app connections, complete the following steps:
The Third-Party Apps section lists the applications that can connect to your organization. Each application shows an ALLOWED or RESTRICTED badge that reflects the current setting. When connections are allowed, a View connections button takes you to the applications that users have authorized.
This setting controls access for third-party applications. To learn about the separate setting that controls access through the Remote MCP Server, see Manage AI Client Access to Your Organization.
Set the Maximum Refresh Token Lifetime
Authorized applications use refresh tokens to obtain new access tokens without prompting the user to re-authorize. As an organization owner, you can set the maximum refresh token lifetime for applications authorized in your organization.
Two limits govern refresh tokens:
Maximum lifetime is the longest a refresh token remains valid. When a token reaches this limit, the user must re-authorize the application, regardless of activity. The default is 30 days.
Idle lifetime is how long a refresh token remains valid without use. A token that is not used within this period expires. The default is 7 days. The idle lifetime can never exceed the maximum lifetime.
In the Atlas UI, an organization owner can adjust the maximum lifetime. You can customize the idle lifetime only through the Atlas Administration API, not the Atlas UI.
Note
Default lifetimes are configured per OAuth client, so the default that applies depends on the client that connects.
To set the maximum refresh token lifetime, complete the following steps:
After you save, the section displays the current maximum lifetime. To change the value, click the edit icon.
Unlike the setting that allows or restricts third-party app connections, the maximum refresh token lifetime is a single organization-wide setting. It applies to every app connection in your organization, including clients that connect through the Remote MCP Server. To learn about those clients, see Manage AI Client Access to Your Organization.
Clear the Maximum Refresh Token Lifetime
To remove the maximum refresh token lifetime that you set for your organization, click the delete icon next to the current value, then click Clear to confirm. After you clear the setting, the effective lifetime returns to the default for each client.
View Authorized Applications
You can review the third-party applications that users in your organization have authorized, with metadata about each connection.
The connections page for an application lists each connected member with the following details:
Users: the Atlas user who authorized the application.
Last used: when the application most recently acted on that user's behalf.
Last authorized: when the user most recently authorized the application.
Limitations and Responsibilities
Important
Disabling an application's access does not remove resources the application created. Atlas does not automatically delete database users, service accounts, API keys, or other resources when you disable access. Cleaning up these resources is your responsibility. Until you remove them, these credentials remain active in your Atlas account and can retain data plane or control plane access.
When you disable an application's access, be aware of the following:
Atlas does not automatically delete database users that an application created on behalf of your users. These database users, and their connection strings, keep working after you disable access.
Atlas does not automatically delete service accounts or API keys that an application created. These credentials retain control plane access until you remove them.
Atlas does not automatically delete other resources that an application created, such as clusters or projects.
Existing data plane connections remain active until they close through normal connection lifecycle events.
To fully offboard an application, see Offboarding Best Practices.
Offboarding Best Practices
When you stop using an application, disabling its access is only the first step. To fully offboard an application and protect your data, complete the following cleanup:
Delete any database users the application created on behalf of your users if no other application or workload depends on them.
Before deleting a database user, confirm that its connection string is not shared by another application or workload that still needs access.
Delete any service accounts or API keys the application created, which otherwise retain control plane access.
Review and remove any clusters, projects, or other resources the application provisioned that are no longer needed.