This is a hard question because both types of persistence have advantages and disadvantages. But, since we are taking about a CQRS Read model (I will use this term for Materialized view) (assuming that the authentication operation is done read-only, i.e. by a query) we could think about the following considerations:
for each type of supported authentication scheme you could have a different implementation; i.e. username/password using NoSQL and one-time-login-by-email-link using SQL
some authentication schemes like username/password are easy to implement; you could implement it for both persistent types and use benchmarks or A/B testing to decide which one to use; this is simple to do thanks to CQRS and Event sourcing by subscribing both Read modes to the relevant domain events
both have solutions for availability: SQL and NoSQL have some kind of replication solutions (master/slave or replica sets) but thanks to CQRS you are not forced to use the built-in replication; you could just have multiple instances of the same Read model running on different nodes; here depends more on the operational costs
both have solutions for horizontal scalability, like sharding; but again, thanks to CQRS you could implement sharding yourself by creating a table/collection for each region or country or whatever dimension makes more sense; or you could combine the built-in sharding with this technique
NoSQL makes it easier to store/retrieve the entities but if the Read model is simple (i.e. user ID, username and hashed password) SQL works too
So, it depends on each authentication scheme that you will support, on how much code you will write, on the operational costs of replication/sharding etc.
