Hacker News Reader

Comment by dilyevsky | Hacker News Reader

If you use mTLS client identity is proven cryptographically (normally via /CN x509 field) - no need to exchange the key during authentication. You still need to generate it and distribute it to the user and manage its lifecycle which gets you to the same place as OAuth except with worse library support

View on HN

> no need to exchange the key during authentication

The public key does need to be exchanged, along with a signature relating it to the current session. This is all handled by TLS, there is no need for the client to send the key in the application data.

> You still need to generate it and distribute it to the user

This approach avoids distributing secret key material at all. Private keys should ideally never move. They are generated randomly, used to derive the corresponding public key, and then persisted as appropriate. The public key is sent around to other parties.

How do you ensure someone else didn’t just create a new cert with the same user id? At the minimum there needs to be a step to sign the public key (with another flow to prove csr requester identity) Do you see how this a lot more moving pieces than oauth the user needs to figure out?

If you’re suggesting to just store a cert thumbprint that means a db call on every request - no different than just a secret token.

I like mTLS, I've worked in scenarios where both mTLS and OAuth are used separately and together, but if the comment here is suggesting certificates will be less complicated than OAuth then I would say I spent an equal amount of time banging my head against the wall with regards to learning and wrangling both, but maybe that's just me, would appreciate anyone else with experience in both to add their take.

Reply on news.ycombinator.com