HTTP Is Stateless — That's Why You Need a Token After Login
Nearly every API that authenticates users relies on this pattern. Misunderstanding the stateless nature of HTTP leads to broken auth flows, and confusing login with authentication is a common source of 401 errors during development.
HTTP's stateless design means each request arrives as a blank slate; the server has no memory of who just authenticated. After a successful login, the server must hand back a credential — a JWT — that the client attaches to future requests via the Authorization header. That token carries a signed payload of user identity and an expiration, letting the server verify who is asking without maintaining server-side session state.
Generating the token uses `jwt.sign()` with a server-side secret and a payload like `{ user, role }`. Verifying it on protected routes uses `jwt.verify()` with the same secret. If the secrets don't match, the token is rejected as invalid. The flow cleanly separates login (proving who you are) from authentication (proving you already logged in).
In practice, the frontend stores the returned token and sends it as `Authorization: Bearer <token>`. The server extracts the token, verifies it, and either grants access or returns a 401. The entire mechanism reduces to two operations: sign and verify.
Many developers conflate login with authentication, which leads to confusion about why a separate token step exists at all. The statelessness of HTTP forces this separation.
The entire JWT workflow in a typical demo collapses to two function calls — sign and verify — yet beginners often overcomplicate it by trying to memorize the token structure first.
Using a mismatched secret between sign and verify is a frequent debugging pitfall that produces opaque 'Invalid token' errors with no obvious cause.