These docs are for AuthRocket 1. Looking for AuthRocket 2 docs?

Migrating data into AuthRocket

Migrating data into AuthRocket is generally straight-forward. Our API is full-featured, and nearly all data can be directly created and managed via the API.


The primary exception are user passwords.

If your existing password datastore uses BCrypt, then we can arrange a bulk import of the raw BCrypt hashes. We generally recommend creating the user records in advance (and setting random passwords) and then we’ll replace the BCrypt password hash with data from a CSV. Contact us to arrange for an import of this sort.

If your app has been storing raw passwords, you’re making an excellent decision by moving to AuthRocket. Simply use our API to create Users with their passwords. Also consider whether it’s appropriate to have all users change their passwords.

If existing passwords are hashed using any other format, you have a few options for how to proceed:

(1) Treat those hashes as the passwords from our point of view. This in effect creates a double hash: your existing hash and then our use of BCrypt.

The upside of this option is that you can fully migrate all data upfront.

The downside is the need to self-host all logins and signups (that is, you cannot use hosted logins or authrocket.js) and you cannot reset passwords using our web UI. This is because you’ll need to pre-hash all incoming passwords before handing them off to us for each login.

(2) Start off like option 1 above, but over time, replace the double hashed passwords with normalized single hashes. Basically, when a user successfully logs in using the hashed version of their password (instead of directly submitting their password to us), immediately follow up by replacing their password with that original, non-hashed version.

The upside to this approach is the effective longterm migration of passwords without the double-hashing. It also allows use of authrocket.js and the web UI for signups and password resets.

The downside is a little extra complexity in the login process (which continues to need to be hosted within your app).

(3) A different approach is to reset all user passwords, either upfront or when they go to login the next time. While potentially a bit dramatic, this has the benefit of being a thorough, complete resolution to the issue at hand. It also ensures the ability to take advantage of all AuthRocket features, both present and future.

We recommend being extra attentive to communication with your users and pointing out that this process improves the security of their passwords.


If you have a large amount of data to import, it may be necessary to throttle the import process to avoid hitting API rate limits.

Questions? Find a Typo? Get in touch.