I'm currently building a new application and trying to apply some of the principles of Clean Architecture. One of my first roadblocks is implementing my own Identity system (to avoid being tightly coupled to the AspNetCore.Identity library.

One of my concerns is password hashing and generation. I'm looking at following a similar or the same process as the AspNetCore.Identity Password Hasher, but I'm not quite sure where I should handle this logic.

My initial thought is since this is pertaining to my domain entities, I should put this in my Domain layer. However, I'm concerned that this will create headaches and scattered logic in the future as I validate passwords. On the other hand, I could define my own IPasswordHasher interface in my application layer, but this has the negative consequence of my application layer dictating my hashing and validation scheme. In the event I share these entities with another application in the future, I would have to ensure that the hashing algorithm is the same.

But by that same token, it would be great to simply use the IPasswordHasher interface that's already defined in Microsoft.AspNetCore.Identity, but I don't want to have that tight coupling.

So what would be the ideal approach to implementing some sort of hashing logic (potentially even just using the PasswordHasher defined in AspNetCore) without having to reference the AspNetCore library in my application/domain layers? And where should I actually implement my password hashing, at the domain layer or the application layer?

Identity management is probably not part of your core problem domain, therefore it has no place among your core business logic. Also, your entities (the center in the Clean Architecture) should not depend on external systems such as databases or possibly specific identity management systems. Instead, you define an interface for the services required by the core, and then implement that service. This implementation would be on a similar level to an “application layer”, but note that the Clean Architecture specifically does not have up–down layers, only inside–out layers. The inside parts define interfaces that are implemented on the outside.

From the perspective of your core problem domain, the exact identity management scheme and password hashing algorithm is indeed irrelevant. It is therefore correct that these details are are decided by an external service. Of course that service could be implemented incorrectly (e.g. storing plaintext passwords), but so could any identity management within your entities. But exactly this possibility of things going wrong also implies flexibility that can be used to make tests go fast. Secure password hashing algorithms are perceptibly slow, by design. So you may not want to use the true identity management implementation for some tests but swap it out with a mock implementation!

“In the event I share these entities with another application in the future …” – no, that kind of assumption is usually wrong for two reasons. First, entities are the central model of your application. This is usually unique and not reusable. Second, consider YAGNI. Iff the need to reuse some component arises, you can refactor your code to make it reusable. That's the luxury of developing an application: you can change the design later. In contrast, libraries that are consumed externally do have to get their API design right the first time.

Note also that the whole goal of the Clean Architecture is to defer design decisions as long as possible. That's why dependencies only flow inwards. You can write your core business logic, without worry of how anything will actually work. If it needs an external service, you define an interface that you implement later. How? That's for the future to determine. The Clean Architecture implies a top-down approach to design. Decisions like choosing an identity management solution or choosing a web framework (or even choosing whether the software is a web app or a desktop app) can be deferred, at least in theory. I find this quite similar to the “Programming by Wishful Thinking” technique taught by SICP.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.