WebAuthn and JWTs are often compared as if they solve the same problem. They do not. WebAuthn is about how a user proves identity. JWTs are one way a server can represent authenticated state after that proof succeeds.
That distinction matters because it changes the architecture conversation completely.
Where WebAuthn Fits
WebAuthn gives you origin-bound, phishing-resistant, public-key-based authentication. A browser flow can start like this:
const credential = await navigator.credentials.get({
publicKey: optionsFromServer,
});
The important point is not the API call. It is the security property: the credential is bound to the origin and backed by public-key cryptography.
Where JWTs Fit
After authentication succeeds, the server still needs to maintain a session model. That could be:
- an HttpOnly cookie
- a JWT
- an opaque session id
JWTs are about session transport and claims representation. They do not make authentication phishing-resistant by themselves.
That means a strong architecture can look like: WebAuthn for user verification, then an HttpOnly cookie or another session token for ongoing state. Those layers cooperate. They do not compete.
Better Rule
Use WebAuthn to improve the sign-in ceremony. Choose JWTs, cookies, or opaque sessions based on how the rest of the platform handles state, revocation, and browser security.
WebAuthn can strengthen the system regardless of which session token format comes next.
Further Reading