There is a reason why they want you to create your own context and class to manage and handle your business logic.
Just imagine what will happen, if, Microsoft ships an update and that changes most of the code (if not all) from the
IdentityDbContext<T> type. Can you afford such a build-breaking change? Because you are now having everything inside a single file, and that file can be easily changed by an update for the runtime/platform or package.
I could not handle the minor changes they made back in ASP.NET Core 1.1 to ASP.NET Core 2.0. I could not, and see this is what happened back then,
Mission Impossible: Migrating .NET Core 1.x to 2.0[
^].
That is why, I recommend keeping multiple contexts, there is no harm in it and for a normal more-than-personal project, there are usually multiple contexts, each handling its own purpose and connection to databases.
You are welcome to try, and share your experience here on CodeProject, I would like to read what happens! :)
Submit an article or tip