Store user data in auth server or resource server? Or both?

With seperation of concerns and single responsibility in mind:

There is not just one user table. Fields in a table have only meaning within the context.

A user can have a google account to login, but for the business that is not the account where you can reach the employee. And how about showing information on a report that is not part of the context? Suppose you store city in the identity context. Then how are you going to show that information on a report? You'll need the information in the business context.

Also consider whether the identity context is a good place to store information. Because the user is in control. What happens when the user doesn't give consent for using the information, or simply removes the account? And what strategy to use when you would like to synchronize data?

Sharing contexts is a no go. Identity is the responsibility of IdentityServer, the identity context should only contain information about the identity and is only accessible by the IdentityServer. Please note that IdentityServer is not bound to one app.

You'll need a user table in each context. Where information may seem redundant but actually is not, because it is part of the seperate context. Like when you login using a provider like google. Then a local copy of the user is created in the identity context.

But perhaps you should not refer to it as User in the business context. Because within the business context there are no users. Most likely they are employees, customers, etc. Who can have a login, but not necessarily. And it's possible to have (identity) users that are unkown to the business (e.g. in case of multiple apps).

IdentityServer is the authority to authenticate the user. Authorization can be implemented on multiple levels. You can create a seperate authorization server (like policyserver). Or lower level (resource-based), where the existence of a user inside the 'person' table means that the user has access to the resource.

The best part of seperate contexts is that within the context you can create relations between tables, without interfering with other contexts. You can easily switch to a different oidc provider, if you'd like. But once you start to mix contexts, there is no way back.

The one thing that is very useful in oidc is the sub claim. Simply look up the user by the sub claim and use the local id for the business context.

About the fields city and country in the identity context: there are multiple levels of authentication, so you may actually need the information in this context. But if you need the information in another context (e.g. to show on reports) then it should be added there (as well).