Not a question. Locking.

Sounds like you are talking about passkey authentication. Being able to prove who you are based on something that is you.

I'm not sure I understand what you're proposing to use as a fingerprint, or what

checking if enough of the fingerprint hashes match with the key

means, however at the end of the day all server-client authentication and authorization works by passing a "password" with the request to prove who you are. Whether that's a passkey, session token, jwt, actual password or a salted and hashed fingerprint doesn't change where the security leak for session hijacking is: stealing whatever it is you keep passing along.

You are sending the server something to prove it's you, and if I steal it I can pretend to be you.

This can be mitigated with short lifespans for those "passwords", or using cryptography. However, cryptography is expensive and usually already included somewhat by using https, and short lifespans (which I think your multiple fingerprint hashes refers to?) eventually lead to poor user experience by requiring frequent logins or very quick usage because the tokens run out before they can be refreshed.

Biometrics are a username not a password. Authentication is not authorization. This sounds like trying to stop man in the middle attacks with something susceptable to man in the middle attacks.

Maybe I'm just not getting the idea.