mTLS authentication

Summary

Mutually authenticate client and server. This is useful for production grade server/server and provides a high level of security.

Details

In mTLS the client is configured with a public server certificate, while the server has a public client certificate (of course it could each also be multiple certificates for multiple servers/clients).

The client contacts the server, which send's a token signed with its private key. The client then verifies the signature with the server's public key. Then it sends it a token signed with its own private key back to the server, and the server validates the client's authenticity by checking against it registered public client keys. All this is basic asymmetric encryption technology.

Note that the server may also verify the client's via a higher-level certificate, if the clients are signed by some (root) CA. This is basically normal TLS certification.

Risks

• Critical:
• Normal:
• Minor:

I think mTLS is an extension of the normal TLS handshake, where only the server is authenticity is validated by the client (e.g., using a certificate chain; e.g., with the browser).

Verification & Validations

• Connect with and without registered certificates. Fail client authN if the client's signature key is not certified/registered, otherwise succeed.

Important Stakeholders

OTP? Clarify with @borufka , whether it makes sense to switch the authentication mechanism, and when this should be done.

Implementation Suggestions (optional)

Like API token authentication (#445 ) also mTLS can be implemented with Traefik plugins, or natively.