I am developing a website with general requirements: users can register, confirm their emails, log in, access specific resources based on their roles/claims.
Microsoft Identity provides a simple way to do this.
However, by default does not do any encryption, and I would not want anyone's email address to be leaked.
There is a way to introduce cryptography using an implementation of ILookupProtector, and using the ProtectedPersonalData attribute. However, even Microsoft strongly advises against doing so, and strongly suggests using the builtin encryption of a DBMS, for example SQL Server (Always Encrypted). Always Encrypted is supported by Entity Framework, so theoretically it would be possible to alter the migration created by EF so that a column encryption key is applied to the email column.
It seems almost good enough, but as per the documentation of Microsoft queries that involve encrypted columns can't be used anyhow (for example you can't compare them to constants directly). So I do not know if I made this modification to the email column would end up in some unknown behaviour inside Microsoft Identity, because it expects the database not to be encrypted...
For all this, currently I am writing a solution that completely circumvents Microsoft Identity: I choose which user data I want to store, I create the ClaimsPrincipal object based on these data, and I log in the user using HttpContext.SignInAsnyc instead of signing in the user with SignInManager, and I will need to generate the email confirmation token myself instead of using UserManager.
I am still thinking if it would be safe to use Always Encrypted with Microsoft Identity?