Find if user id already exists in the cloud DB


How would I go about finding if a user ID already exists. I’m trying to implement my own username/password auth flow using jwt since documentation strongly recommends not using the built in feature; and I’m trying to find out if a userID already exists in the database upon registration.

It seems like I could try using retrieveAccount(provider, username) -> Promise and process the promise it returns. Is there a recommended way of doing that is I guess what I’m trying to find out?

Hope the documentation will be refreshed soon.

Thank you,

If you’re implementing your own login flow, you should store the user accounts/passwords in your own database. The documentation recommends not using the built-in one because it is incomplete - e.g. it doesn’t support two factor authentication, security questions, and so on. If you are fine with the limited set of functionality it provides, you are welcome to use it.

Thanks for the quick response, Nikola. I’m fine with the limited set of functionality as long as it’s robust enough security-wise. Do you think you could elaborate more on the strategy used to keep the passwords safe? (e.g., hashing, salting rounds if any etc) I couldn’t find any of that in the documentation.

There are no known security vulnerabilities when using password auth and we have tried to adhere to best practices when dealing with passwords. We use PBKDF2 for hashing passwords and by default the key length is 512 bytes, the number of iterations is 10000, and the salt length is 32 bytes. We also don’t log passwords in our operational logs. If you have more specific questions about it, I’d be happy to answer - as I said, I feel like the limited set of functionality the password provider offers is reliable and secure. That being said, a major portion of attacks nowadays are executed through social engineering or by trying reused passwords from hacked services. The fact that we don’t support two factor authentication and there’s no way to enforce password length on the server means that your users will be vulnerable to those types of attacks (you can always enforce password length/complexity rules on the client of course).

That makes sense. Seems good enough to me. Thanks Nikola.