Are my users locked into MongoDB App Services?

Hi @Jesus_Santin. I was able to query for all of my users using the Atlas App Services Admin API. You can check that out here. I don’t use email/password, so not sure on what you’ll get back, but hopefully it gets you going in the right direction.

Hi @Jesus_Santin I have also started looking into the topic of migrating away from Atlas as an authentication provider.

My current guess is that we are probably able to get the user data via the Admin SDK, and recreate user entities with a different provider, with social logins such as Sign-in-with-Apple and Sign-in-with-Google not being a problem, because the external user id stays the same.

But for email-password we most likely have to give every user a temporary password and request them to reset it

I agree! Some sort of export would be great. We, the developers using MongoDB Atlas App Sync, are already frustrated with MongoDB’s decision, would be nice if we don’t need to have this customer-facing too.

@Joel_Lord to quote you in your previous post in the other thread, this would be one way for you to “[…] develop resources to help you navigate this migration process.”

Thanks @Joel_Lord for the information.

I’ve been using the Admin API to fetch user data for a while now, so I am also believe it could be sufficient to map the identities to another provider.

But if we do not get any (hopefully hashed) user credentials with the user data, there is no way to have a non-disruptive user experience, and every single user will have to reset their password.

This problem is not exclusive to MongoDB Atlas, as this could happen with every authentication provider (inkl. Auth0), but as you are planning to shut it down anyways, it would be really helpful if you could allow us to export the hashed passwords too.

Whatever new authentication provider we are going to use, they still need to support us importing users and hashed passwords too, but you could at least support us here, to have complete data.

@Joel_Lord
Any update on this, or is this information you don’t have?

@Joel_Lord

This deprecation is a major blow to my app and business, and we’re struggling to keep up. I feel like the team may have underestimated not only the time we need to migrate to a new stack, but also the amount of effort we’re putting into researching alternatives to avoid ending up in the same situation again. This process is taking a lot of time, and if we make the wrong choice, we risk not finishing in time or having to start over if the new service gets discontinued as well. It’s a tough spot to be in.

@klaassum My understanding is that Authentication will effectively be deprecated as the SDK’s are all being deprecated and the community device libraries will only house the local “Realm” databases (which are NOT going to be supported by Mongo team members). As I now understand, the only part of App Services that will be left are triggers and functions (I assume all run as system user in future).

Alright, thanks for the reply!
Sad, it was a nice product

Hello,

Any news on this?

I also use MongoDB authentication: email/password, Facebook, Google, Apple ID.
Did anyone manage to export the users somehow?

Thanks!

Hi everyone, I had a conversation with the MongoDB support a while ago regarding the topic. Here a short summary of what was said and what we’ll do next:

• We can export the users using the Atlas Admin API
• They will not allow us to export the email + password hashes due to security reasons
• You will have to ask every user reset their password, or use password-migration.
• In our case we are transitioning to Ory Kratos as the authentication provider.
• Ory Kratos allows password-migration, which basically does the following:
  • Client wants to login with EMAIL and PASSWORD at Ory Auth Endpoint
  • Ory Auth Endpoint checks database, if EMAIL not found, it forwards the authentication request to Realm Auth Endpoint.
  • Realm Auth Endpoint will check the existing email and password combinations, and returns a session if valid
  • Ory Auth Endpoint receives the valid session from Realm Auth Endpoint, therefore knows that the EMAIL + PASSWORD combination is valid, and saves it the to the Ory Kratos database.
  • Next login with EMAIL will check the Ory Kratos database, instead of using Realm Auth Endpoint

You can probably create your own authentication proxy/password migration function using a proxy server or custom solution.

What about the users that created an account using Facebook, Google, Apple ID login?

AFAIK as long as you do not change the OAuth app, so use the same client id of your provider, the user id in the OAuth ID Token will stay the same.

Basically when logging in with i.e. Google, you get an id token which is then send to App Sync.
Sync then uses the token verification endpoint of Google to check that the token is valid.
As only the owner of a Google Account can create a valid id token with the google account id in the payload, if it is valid, then Sync uses the user is in the payload to select the authentication id.

when migrating to another authentication backend with the same OAuth endpoint and client id, the id stays the same.

There is no password hash stored in Sync, so there is only the user oauth id to export

@Joel_Lord Will the Atlas Admin API keep working after September 2025?

If we need to check user information after that, for instance, which providers they used, or what email address is linked to which user ID, will we still be able to use Atlas Admin API to check that information, or should we plan to export all data before that?