It sounds like you are thinking of micro-services as separate applications, which a user interacts with directly. While some might work that way, a better mental model is that each micro-service is a component within a single application, and the user is interacting with the application as a whole.
Each micro-service has its own set of entities or resources that it is responsible for, and which are relevant for its purpose or domain.
Take for instance a micro-service responsible for managing product stock in the warehouse of an e-commerce company. The end-user of the application might be a user searching for products, but they don't own any resources in the warehouse, so there is no need for them to be persisted anywhere in the warehouse micro-service. The permissions model of the warehouse service only needs a fixed role which grants all customers the same read-only access to the stock levels.
The example of a "user profile service" is different. This service has a responsibility which involves modelling users, and making information about them available to the rest of the system. It definitely needs a persistent "user" entity. It's slightly unclear to me what a "profile" would be as an entity, but you might first create a "user" entity, and then add a "delivery address" entity, a "login credentials" entity, and so on.
Other services might reference users, but not manage them. For instance, an "order history" service would need to record which orders belonged to which users, but those users would simply be references to the entities already created in the user profile service. There wouldn't, for instance, be a "Users" table in a database used solely for the order history service. There might be some other entity which had exactly one instance (e.g. one database row) for each user, but that wouldn't be a "user" entity, it would be something specific to the domain of "order history".
