Identity management is probably not part of your core problem domain, therefore, it has no place in your core business logic. In addition, their entities (the center of clean architecture) should not rely on external systems, such as databases or, possibly, specific systems of identity management. Instead, it defines an interface for the services required by the kernel and then implements that service. This implementation would be at a level similar to an "application layer", but keep in mind that the clean architecture specifically does not have layers from top to bottom, only layers from the inside out. The internal parts define interfaces that are implemented abroad.
From the perspective of mastering its central problem, the exact scheme of identity management and the password hashing algorithm is irrelevant. Therefore, it is correct that these details are decided by an external service. Of course, that service could be implemented incorrectly (for example, store plain text passwords), but any identity management within their entities could also do so. But exactly this possibility of things going wrong also implies a flexibility that can be used to make the tests go fast. The hashing algorithms for secure passwords are significantly slow, by design. Therefore, you may not want to use the true implementation of identity management for some tests, but change it to a simulated implementation!
"In the event that you share these entities with another application in the future …" – no, that type of assumption is usually wrong for two reasons. First, entities are the central model of their application. This is usually unique and not reusable. Second, consider YAGNI. If the need arises to reuse any component, you can refactor your code to make it reusable. That's the luxury of developing an application: you can change the design later. On the contrary, libraries that are consumed externally have to get their API design correctly the first time.
Keep in mind also that the whole goal of clean architecture is to postpone design decisions as long as possible. That is why the dependencies only flow inwards. You can write your core business logic, without worrying about how something really will work. If you need an external service, define an interface that you will implement later. How? That is for the future to determine. Clean architecture implies a top-down approach to design. Decisions such as choosing an identity management solution or choosing a web framework (or even choosing whether the software is a web application or a desktop application) can be postponed, at least in theory. I find this very similar to the "Programming for good wishes" technique taught by the SICP.