Show HN: Bifrost MTLS Authentication (opens in new tab)

Yeah I understood this, the issue I'm facing here is the following:

When I grant access to services/information based on certificates presented to me by a client, then I want to make damn sure that the certificate is not handed out to someone that shouldn't have it.

So reading stuff like this:

    The server is stateless and doesn’t store any information about clients. The server is also unauthenticated, meaning that anyone can request a certificate. 

I'm not entirely sure if I want that. Also I'm not entirely sure if I want to sign certificates w/o having any kind of log so that I can revoke those later.

Similar to this:

    Operators use an out-of-band mechanism to verify and trust client UUIDs.

and this:

    Place it behind a network-based protection mechanism (reverse proxy, secure gateway, firewall);

So I have to provide a mechanism that allows me to identify the client in the first place to then hand out certificates that are being used to identify the client. It feels like we're either producing a security problem (no checks, see above) or we’re fixing an issue we don’t have as we’re already able to identify the client properly, while that identification needs to be done by other means that usually involve API-keys, passwords or similar things.

Which one is it?

Don't get me wrong here, I'm sure there are certain scenarios where mutual or client authentication can only be done using X.509 certificates, I’m not denying that, I just don’t understand how this scenario should play out.