In essence, when client and server handshake, a unique session ID is generated. The server can associate this ID with a user account and use it to identify the user on subsequent requests. Except this works only when client and server are connected directly. If there is a CDN in front of the server, or a proxy in front of the client, the session ID will refer to the intermediary devices, which may be used among many users, and so on. In addition, clients can (and often do) throw away TLS sessions very frequently. The last time I tried this technique (admittedly some two decades ago) Internet Explorer was rotating the session ID every 5 minutes.
There is something called Channel Binding (or Token Binding, the names have changed a couple of times) that can be used to create a cryptographic identity at TLS level. It's the same idea as session ID binding, just properly secure. Google spent a lot of time experimenting with it but IIRC ultimately decided against it. Here's a link to the slides from a couple of years ago: https://tools.ietf.org/agenda/90/slides/slides-90-uta-0.pdf
There is also in TLS something called pre-shared key (PSK) authentication, which is a way to handshake without certificates, but client and server have to share a password instead. (In TLS 1.3, the PSK mechanism is also used for session resumption.)
It is imperative to understand that passwords are not suitable for a TLS 1.3 PSK.
I even ran into this with some people working on CMP in LAMPS ("Limited Additional Mechanisms for PKIX and S/MIME" the poor group left with the work that couldn't be avoided entirely to fix problems in PKIX and/or S/MIME)
No, you can't just run the password through PBKDF2 and consider that good enough. If you really need password authentication, you need an actual password based authentication mechanism, do not try to jury rig PSKs.
And in that case you're right, TLS 1.3 PSKs made this way would in principle be safe because they meet the high entropy requirement. If I guess "OpenSesame" I can't guess the PSK because I don't know the salt.
But, wait, if we have enough shared entropy that's secret then we already have a suitable Pre-shared Secret Key and we didn't need to invoke PBKDF2, our design is over-complicated.
So why do people want to do PBKDF2 at all? Well of course they don't have that shared secret entropy, they were hoping "OpenSesame" was good enough and that if they can just squint hard at the PSK feature surely they can use their password for it, which is why TLS 1.3 explicitly cautions them not to do so.
What surprises people here is that there's a viable offline dictionary attack. What they tend to be imagining is that a hypothetical bad guy has to try connecting with password "Pass1234" and then try again "LetMeIn" and then again, and again, until they try "OpenSesame" and so that seems impractical.
But TLS 1.3 does afford a dictionary attack, during the unencrypted ClientHello the client sends over enough information for an attacker to confirm whether a PSK they've guessed is correct. So the attacker just collects that information, then they get to run an offline dictionary attack.
This isn't a threat for a good PSK because it's just random. You could try such an "attack" on everything else in TLS, and it would be just as (in)effective. But for a human memorable password of course dictionary attacks are a real threat because there may be only millions or even thousands of likely guesses.
I think you still need to have mTLS or another credential to use initially for auth. Unless I miss an option. As such I don’t see much value over mtls in a corporate network setting.
Basically, you need to get the session ticket from the webserver being available at the backend, and set its lifetime to something reasonable.
At least NGINX can then handle all of the session resume/renew logic by itself.
People were always surprised how they stay logged in after clearing cookies.