Symmetric uses one shared secret key and is fast; asymmetric uses a public/private key pair and solves key distribution, but is slow, so protocols combine them.

The two are complementary. Symmetric crypto has the speed but needs a safe way to share the key; asymmetric crypto provides that way but is too slow for megabytes of data. So TLS, S/MIME and VPNs are hybrid: public-key operations authenticate the partner and agree on a fresh symmetric session key, and AES (or similar) then encrypts the actual traffic.

That leaves one open question, which is what a PKI answers: when someone hands you a public key, how do you know it really belongs to them? A certificate binds the key to a name, signed by a CA you trust.

Go deeper:

• Computerphile: Public Key Cryptography — a six-minute intuition for key pairs, with no maths.
• Wikipedia: Hybrid cryptosystem — how protocols wrap a symmetric session key with public-key crypto.
• Wikipedia: Public-key cryptography — key pairs, signatures and key exchange side by side.

Username/password, then one-time passwords, then challenge-response, then certificate/verify: each step stops sending a reusable secret over the wire.

1. Username/password. The user sends a name and password; the server compares it with a stored (ideally hashed) value. Weak points: the secret travels on every login, so it can be sniffed, phished or grabbed by injected script, and weak passwords fall to dictionary attacks against a stolen hash file.
2. One-time password (OTP). Every password works exactly once (a TAN list in online banking, an RSA SecurID token). A captured password is worthless afterwards, but the user still types and transmits it.
3. Challenge-response. The server sends a random number (the challenge); the client proves it knows the shared secret by encrypting or HMAC-ing it and sending back the response. The secret itself never crosses the network, and a recorded response is useless because the next challenge differs. Used by mobile networks (SIM authentication) and CHAP.
4. Certificate/verify. A public-key variant of challenge-response: the client signs the challenge with its private key, and the server checks the signature with the public key from the client's certificate. The server no longer needs to hold any secret of the client at all. TLS client authentication and IPsec IKE use this as a building block.

Beyond these protocols, any factor can be classed as something you know (password), have (token, smart card, private key) or are (biometrics). Combining two classes gives multi-factor authentication.

Go deeper:

• Wikipedia: Challenge–response authentication — variants, including signatures over a nonce.
• Wikipedia: One-time password — TAN lists, HOTP/TOTP and hardware tokens.
• Wikipedia: Authentication — the knowledge / ownership / inherence factor classes.