Sessions and tokens

HTTP has no memory. Every request your browser sends arrives at the server as a stranger, so an app needs a way to say "this is the same person who logged in a minute ago."

Sessions

After you log in, the server creates a session: a record that says "user 42 is signed in until 6pm." It hands your browser a random session id in a cookie. Every later request carries the cookie, and the server looks the id up.

The server holds the truth, so logging out, or kicking a stolen session, is instant: delete the record.

Tokens

A token (often a JWT) flips that around. Instead of a lookup key, the server hands you a signed statement: "user 42, role admin, valid until 6pm." Any server with the signing key can check it without a database lookup, which is why tokens scale well across many servers.

The cost: a token stays valid until it expires, even if you log out. That is why real systems pair a short-lived access token (minutes) with a refresh token that can be revoked.

Where DontCode fits

Your app's auth pool issues short-lived access tokens and handles refresh, cookie flags, and revocation for you. Session length and remember-me are settings, not code.