Should I separate my application context from ApplicationDbContext used for identity?

There is no right answer for this. There is no security issue related to 2 different contexts. It all goes down to your architecture - do you need to create references to users in your domain or not. In separate domains you can't have EF maintaining foreign keys from user tables to domain.

A few times I have started with 2 different dbContexts but got tired of extra maintenance and no gain and merged stuff into one.

And because you are asking about this, chances are that you won't gain anything from 2 separate db-contexts, only add extra code and unwanted maintenance in the future. So I say have only one to start off. You can always separate when you actually need it.

I would create a separate context , mainly for the reason you may need to separate your user account db from your application db at some point. Often an organization's security policy will ask for this.You can always point to the same connection string if you don't have this requirement and still maintain two contexts. I prefer splitting contexts , as it keeps the fluent api for entity mapping limited. Keeping it separate also gives you the option to encrypt your authentication dd and maybe not your app data, which gives you a nice balance between security and performance.

This is an excellent question and one that I contemplated myself.

What if you should want your application to use a domain driven design or onion architecture?

Membership and Identity components are infrastructure or application layer components.

Application entities are often considered domain layer components.

If you use a single context, you'll have a lot of difficulty separating the entities of your context into separate layers without compromising the integrity of your architecture.

Let me know what you think in the comments?