Following the recent news about the deprecation of Atlas App Services, I have started planning my migration to another service. I currently use MongoDB authentication (email/password) and do not store passwords myself, as this aspect is securely managed by MongoDB.
My question is: how can I migrate my production users to another authentication provider, such as Firebase? Is there a way to export or transfer their credentials, or are they locked into MongoDB’s deprecated 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.
I have tested the API and I am able to retrieve all the users. However, unfortunately, the response does not include the passwords, so I am unable to export them to another authentication service. Thanks anyway!
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
Thank you, @philprime In that case, the management of user credentials adds an additional problem to the ones we’ve already faced with the migration of code and services to other platforms.
If we are not allowed to export the credentials, I believe MongoDB should enable an on-demand transfer — at least — to any of the three main cloud providers.
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.”
While not explicitly about getting user data, you can follow this tutorial to get started with the Admin API and Postman.
As far as a replacement, Auth0 is a strong option for authentication, and they have a free tier. You can refer to their docs for more information about how to import user data.
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.
Thank you for taking the time to respond to our concerns. What’s a bit missing from all the responses and announcements is what parts of Atlas App Services will continue to exist, that creates a lot of questions.
More in line with this topic, you talk about how Auth0 is a good alternative, does this mean that in the future you will also do away with “App Users” (Authentication)? The same goes for rules, schemes, …
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).
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.
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
