As the others said, private keys aren't shared. full stop. Otherwise, they are called public keys.

But: Cryptographically signing on is pretty standard. HTTPS supports that:

Authentication using HTTPS client certificates; and all modern browsers have the built-in means to generate the necessary keys when asked to.

Your problem has already been solved; the user generates a key pair, gives you its public key, keeps the private key, and upon connection, the server asks the client to prove they own the private key (essentially, by letting them sign something).

Done!

Other cryptographically established methods include at least one method I'm aware of:

Single-sign on via Kerberos ticket – this is extremely wide-spread in intranets that use Active Directory. Again, modern browsers (at least Edge, Internet Explorer, and Firefox) support this out of the box – on both windows and Linux (haven't tried on OS X or FreeBSD)

As the others said, private keys aren't shared. full stop. Otherwise, they are called public keys.

But: Cryptographically signing on is pretty standard. HTTPS supports that:

Authentication using HTTPS client certificates; and all modern browsers have the built-in means to generate the necessary keys when asked to.

Your problem has already been solved; the user generates a key pair, gives you its public key, keeps the private key, and upon connection, the server asks the client to prove they own the private key (essentially, by letting them sign something).

Done!

Other cryptographically established methods include at least one method I'm aware of:

Single-sign on via Kerberos ticket – this is extremely wide-spread in intranets that use Active Directory. Again, modern browsers (at least Edge, Internet Explorer, and Firefox) support this out of the box – on both windows and Linux (haven't tried on OS X or FreeBSD)

As the others said, private keys aren't shared. full stop.

But: Cryptographically signing on is pretty standard. HTTPS supports that:

Authentication using HTTPS client certificates; and all modern browsers have the built-in means to generate the necessary keys when asked to.

Your problem has already been solved; the user generates a key pair, gives you its public key, keeps the private key, and upon connection, the server asks the client to prove they own the private key (essentially, by letting them sign something).

Done!

Other cryptographically established methods include at least one method I'm aware of:

Single-sign on via Kerberos ticket – this is extremely wide-spread in intranets that use Active Directory. Again, modern browsers (at least Edge, Internet Explorer, and Firefox) support this out of the box – on both windows and Linux (haven't tried on OS X or FreeBSD)

As the others said, private keys aren't shared. full stop. Otherwise, they are called public keys.

But: Cryptographically signing on is pretty standard. HTTPS supports that:

Authentication using HTTPS client certificates; and all modern browsers have the built-in means to generate the necessary keys when asked to.

Your problem has already been solved; the user generates a key pair, gives you its public key, keeps the private key, and upon connection, the server asks the client to prove they own the private key (essentially, by letting them sign something).

Done!

Other cryptographically established methods include at least one method I'm aware of:

Single-sign on via Kerberos ticket – this is extremely wide-spread in intranets that use Active Directory. Again, modern browsers (at least Edge, Internet Explorer, and Firefox) support this out of the box – on both windows and Linux (haven't tried on OS X or FreeBSD)