Migration guidance from ASP.NET Core Identity

Help
, ,
1

Struggling with some concepts on implementing Auth0. I have a backend that currently implements ASP.NET Core, though passwords were hashed before this implementation, so I use a custom password validator.

So I have:

  1. a website that users log onto to manage their account, place orders, etc… (ASP.NET Core Identity)
  2. A custom database that stores customer data, orders, licenses, etc…
  3. I also have a WinForms app that (currently) calls to a web service and just passes username/password to activate software, etc…
  4. Coming mobile app (which is what is driving the migration to IdaaS)

Originally I was going to just going to put IdentityServer on top of my custom stuff, but, I’d rather be hands off so Auth0 seems like a better bet.

Struggling with a few concepts on the implementation.

  1. Let’s start with one of my bigger issues. I will obviously update the Winforms app to use the auth0 login flow. However, I have old users that are incapable of upgrading for various reasons so I need to keep this web service in place at least for a while. I planned to update my webservice to validate the username/password through the Auth0 API instead of my own database, but this seems like its been deprecated and no longer functional? Is that correct? This is problematic.

  2. New user wants to place an order from my ASP.NET Core website. They hit the auth0 login screen and register there. How do I instantly get them into my custom database? It looks like there are hooks and things, but I don’t really trust that in case something goes wrong. In the ASP.NET Core default templates, if you register or logon with a social connection, FB, Google, etc… after you authenticate it sends you to a “Great, you’ve authenticated, but now you need to create your account”. Is there such a sample for that? Is that the best way to go? Seems so… does anyone else have a similar implementation or another approach that works better?

  3. For existing users I’m thinking of just doing the bulk import from the import tool and forcing a password reset rather than the trickle migration? This isn’t really a question more of a thought. Has anyone done this and regretted it?

  4. Password changes, profile updates, etc… do I just keep my existing ASP.NET Core pages in place for this and call to the Auth0 APIs to do this?

  5. For username/password logins (existing users), how do I let them add social connections so they can login with either/or? This is a current capability in ASP.NET Core Identity but don’t see a similar concept in Auth0.

  6. Profile data. Where’s the “line” as far as what I should store in Auth0 vs my own db? First name, last name, etc… but I also have shipping addresses, billing addresses, gender, birthdate, “where’d you hear about us?”, obviously there will be some duplication in data such as name, but just curious where others have drawn the line as “this is what’s in Auth0, this is what’s in my CRM”

  7. Importing users with social connections: It seems like you can’t import social. Is this something that can be added later? I have another app where there are users that only have social connections. I can pull this info cleanly to the bulk import tool but obviously need to import social connections. I’d like to move it to Auth0 as well but see a path unless this is possible.

Thank you!

3

Hi @rev23dev,

Thanks for reaching out and taking the time to write us such a detailed post. I am going to tackle everything I can here, but since there is plenty to unpack forgive me if I miss something.

Here we go!

This is something that is going to require some research on my part, so we will revisit this. (This question may justify a new topic in and of itself.)

  • This can be done by redirecting users in a rule. It will require the user to enter information before continuing.

  • You could also do as you say; redirect a user to a special login page after authentication and have them update information there.

I have not performed a scaled bulk user import first hand, and I cannot speak from experience on that. This is precisely what the Community if for, and could require its own topic to poll experienced community members.

Outside of that, I can say there are several options for migrations. I would point you to this topic where I wrote on different strategies to accomplish a user migration. Generally, the route you take is going to be determined by your desired UX (to password reset or not to password reset, that is the question :scroll: ).

In short, yes. You can leverage the Management API and Authentication API to send a password change email, update profiles, and do this all from your application. You can also do it manually via the Auth0 Dashboard.The Management API can do virtually everything the dashboard can and more!

Account Linking will allow your users to choose their preffered method. It uses email to link the accounts.

This is a blurred line, and it certainly gets crossed. According to our user_metadata/app_metadata docs, “We recommend against using these properties like a database. They should be used for identity related information.” If you think you would use something for authentication, in a rule hook etc., then it could be stored in user/app metadata. Take a look at the link for more information (although your judgment is going to be the final say).

If you were to import you users to a custom Auth0 DB, then turn on account linking, would this solve your problem? It does seem as if you cannot import social because of the ownership by an outside IDP.

Thanks for reading and please let me know if you have further questions.

Also one tip, if you break up your questions into individual topics they are typically easier and quicker for us to answer. :slight_smile:

Thanks,
Dan

4

Thanks Dan I appreciate the thorough response! I will start digging.

For #1, I did think about this more. While it would be ideal to be able to make a call to auth0 with a username/password to authenticate, worst case scenario I can keep their existing password in my DB for a time and call it like “app password” or something and let them just regenerate a random one if needed. Not ideal, but I can work around this :slight_smile:

#2. I will take a look at the redirect rules, not sure I saw those before. Having a sample demonstrating one of these techniques would be awesome though.

#7, I’m not quite sure I understand. Might need additional help on this one. It seems like importing should be an option. I have all the of the same data auth0 requires so I was surprised it couldn’t happen.

5

I still need to look into #1. I’ll get back to you in the next day or so.

For #2 there is an example where a short lived token is issued and the user is redirected to reset a password before finishing authentication. It’s in the doc I linked. If you need some help hashing this out further let me know where you are getting caught up and I can assist.

For #7 I am not positive as to why you can’t import a social connection, but I believe you cannot directly import and create social users because those users are authenticated by their specific IDP (FB, google, etc.). To work around this you would just import those users in a custom auth0 DB connection, and use account liking to link the account information when they log in with one of their social connections. Since account linking relies on similar emails to link accounts, it should be no problem to make sure their old data gets connected.

The flow would be something like this:

I have seen this flow suggested as a solution.

Hope this helps.

Thanks,
Dan