aspnet-identity-mongo | mongodb provider for the new ASP | Identity Management library

The way you've set this up is fine, and the way it should be. The problem seems to be in how Mongo handles the inheritance, although you'd still have a different but equally problematic issue with something like SQL Server.

In short, what seems to be happening here is that you're essentially upcasting UserA/UserB to ApplicationUser, but since the JSON includes properties from those derived classes, which ApplicationUser doesn't, Mongo is choking on it. The solution is to use multiple UserManagers. It's a generic type that takes a TUser type param. The default implementation is UserManager, but that assumes everything is an ApplicationUser. If you have derived user types, then you need to use type-specific UserManager instances for those, i.e. UserManager and UserManager.

FWIW, the problem you'd experience with another data store is that the type that is saved is what determines the value of the Discriminator column added to instantiate the right type with queries. Even if you're creating UserA, for example, if you use an instance of UserManager, it will be upcast to ApplicationUser and saved as ApplicationUser, not UserA. This is similar to what's happening in your Mongo setup, but something like SQL Server would accept it happily (although your data would then be messed up), whereas Mongo is erroring out.

Long and short, always use a UserManager instance that's specific to the user type you're working with.