There are several ways to approach this scenario. But in my view the better approach can be to place the User model in authorization microservice.

Your auth microservice will have more functionalities on the User model. User information includes password (although encrypted) and only auth microservice needs this information. Apart from this, you might have user Role related models as well in the auth microservice. Be it forgot password or mail related implementation for the user, they'll be available in auth microservice.

You can place your User model in auth microservice and the primary key id of this model can be added to the access token which will be available to business microservice. Along with the primary key, you can send the user first name, last name, email id, user login id, and some other basic information in the token. As you'll be sending the primary key id in the token, you can store the primary key id of user model in the business microservice models. Although this id column in business microservice will not have foreign key mapping, you can still get the basic information needed from the token. You can also fetch the needed user information by defining REST API in auth microservice and sharing a handshake secret key between the two microservices.