Create, Delete, and Remove Users
On this page
Atlas Device SDK provides built-in functionality to manage application users, both on the device and in Atlas. Your application can take advantage of role-based data access rules to determine the read and write permissions of a given user. When combined with Sync subscription queries, these features determine what data a user can read and write from a synced database.
The SDK also provides functionality to extend a user object, and manage multiple users or identities:
You can associate metadata or custom data with user accounts.
Users can have multiple identities. For more information, refer to Link User Identities.
Your app can manage multiple users on a device. For more information, refer to Multi-User Applications.
For more information about authentication providers, identities, and user sessions, refer to Authenticate & Manage Users in the App Services documentation.
Atlas Device SDK Users vs. Other User Types
Atlas Device SDK users are distinct from database users or Atlas account users. SDK users are bounded by the App Services App where they are registered, and only have access to resources you provide through the App. Your application can let SDK users:
Call Data API or custom HTTPS endpoints
Read and write from specified collections and databases in MongoDB Atlas through the MongoClient API
SDK users do not have direct Atlas database access, or direct Atlas account access. It is your responsibility to manage these application users, including complying with data retention or deletion policies and regulatory requirements where you publish your applications.
Create Users
For most authentication methods, Atlas App Services automatically creates a user object the first time a user authenticates. The only exception is email/password authentication. When you use email/password authentication, you must register and confirm a user before the user can authenticate to an App Services App.
Automatically Create Users
When you authenticate a user with one of the following authentication providers, this automatically creates a user object for the user:
Anonymous authentication
OAuth 2.0 through Facebook, Google, and Apple ID
Custom JWT
Custom Function
If your app uses email/password authentication, you must manually create users either in the client code or in Atlas.
If you are adding a secondary authentication method, such as adding a OAuth credential for a user created through anonymous authentication, you may want to link user identities instead of creating a new user. For more details about how to link these identities, refer to Link User Identities.
Manually Create Users
If your app uses email/password authentication, your app must explicitly register a user to create the user object in App Services. This method is independent of authenticating a user. For more information about registering email/password users, refer to Register an New User Account.
You can also manually create email/password users through App Services. For more information about manually creating users through the UI, App Services Admin API, or App Services CLI, refer to Create an Email/Password User in the App Services documentation.
Account Deletion Requirements
When you distribute your application through some app stores or in some regions, an app that requires users to create an account also requires you to give users the option to delete their account and any associated user data or metadata. The SDK provides a method you can call from the client code to comply with these deletion requirements. However, this method only deletes the user account; it does not delete any associated user data or metadata.
Following is a resource that provides some details about these account deletion requirements for distribution through the Apple and Google app stores. This is not intended to be a comprehensive list of resources related to account deletion requirements. Consult your distribution agreements and any relevant regulations in the regions where you plan to distribute your application to ensure you comply with all applicable account and data deletion policies.
Delete Users from Atlas
The SDK provides a method you can call from an application to delete the user object. This sends a request to Atlas to delete the user from the server.
Important
Deleting a user only deletes the user object, which may contain associated metadata. This does not delete custom user data or user-entered data from your application. If you collect additional user data, you must implement your own methods or processes to delete that data.
You can use the Authentication Trigger DELETE event to programmatically clean up other data when you delete a user. For example, you can delete the user's data from your custom user data collection or another service.
Calling the user delete method performs the following:
Deletes synced databases associated with the user from the device.
Deletes the
User
object from the Atlas App Services server.Sets the user state on the device to removed.
Because this method deletes any synced databases owned by the user, you should only call this method after closing the user's databases.
If the deleted user wants to use your app in the future, the user must sign up for a new account. They can use the same credentials (depending on the authentication provider), but the new account does not have the same user ID or links to custom user data as their deleted account.
Remove Users from Device
In some cases, you may not want to delete a user entirely, but may want to remove them from the device. In this scenario, users continue to exist in Atlas. You may want to force users to re-authenticate under some circumstances, such as when a paid subscription expires. Or you may want to temporarily persist a user on the server to allow for account recovery.
Removing a user:
Does not delete the
User
object from the Atlas App Services App.Logs the user out if they are logged in.
Deletes synced databases associated with the user from the device.
Sets the user's state to removed.
Because removing a user deletes any synced databases owned by the user, you should only call this method after closing the user's databases.