The key exchange in TLS 1.3 is mainly based on the SIGMA protocol, implementing a "SIGn-then-MAc" variant of SIGMA. I will only describe high-level ideas for the full handshake, other considerations are needed for other handshake like the PSK mode. For an extensive security analysis, I recommend "A cryptographic analysis of TLS 1.3 handshake protocol" by Dowling, Fischlin, Günther and Stebila.
How does TLS 1.3 provide authentication
Zooming out of TLS 1.3, SIGMA builds on an unauthenticated DH and authentication in SIGMA is guaranteed by signature over the communication transcript of the key exchange and a MAC over the identity of the authenticating party. The basic SIGMA flow with mutual authentication between a Client C and Server S is as follows:
- C -> S: $g^x, \text{identity(C)}$.
- S -> C: $g^y, \mathrm{sig}(sk_S, g^x, g^y), MAC(identity(S))$
- C -> S: $\mathrm{sig}(sk_C, g^x, g^y)$
SIGMA is shown (here for example) to provide strong authentication guarantees, key secrecy and forward secrecy even assuming a strong attacker; i.e.: an attacker that fully control the network, that can reveal established session keys, compromise the long-term signing keys of some entities. As a consequence, TLS 1.3 inherits those guarantees, though it makes a few changes like deriving the keys with a more complex key schedule that incorporate the entire transcript in the key schedule.
what is the point of using PKI and Public Key Certificate if the public key is not used to verify that the party has a private key?
Firstly, as seen in the SIGMA flow. The public keys are used to provide signature during authentication. Additionally, a PKI serves as a trusted way to bind identities to public key. This is necessary since a malicious party can impersonate another without any ground truth regarding identities and public keys.
Note that, technically, SIGMA doesn't take maliciously generated public keys into it's threat model. But this is another issue.