Sessions and bearer tokens

Once you have cookies, you can build login flows. Two patterns show up everywhere: server-side sessions and bearer tokens.

With a server-side session, the server stores session data in memory, Redis, or a database. It gives the browser a small identifier, usually in a cookie:

Set-Cookie: sid=7f3a9c; HttpOnly; Secure; SameSite=Lax

Each request sends Cookie: sid=7f3a9c. The server looks up that ID and finds the user’s data. The cookie is just a key, not the session itself.

A bearer token travels differently. The client sends it explicitly, often in the Authorization header:

Authorization: Bearer eyJhbGciOi...

The server verifies the token and decides what the caller may do. The token might contain signed claims (a JWT) or be an opaque string that maps to server-side data.

“Bearer” means possession is enough to use it. Whoever holds the token can act as that user until it expires or gets revoked. Treat session IDs and tokens like passwords.

My rules: always use HTTPS. Never put tokens in URLs where they leak into logs and browser history. Limit lifetime and permissions. Give yourself a way to revoke or rotate credentials when someone logs out or you detect abuse.

Authentication proves who is making the request. Authorization decides what that identity may do. A valid session does not mean the user may delete someone else’s account. Check permissions on every sensitive action.

Try calling an API with curl:

curl -H 'Authorization: Bearer YOUR_TOKEN' https://api.example.com/me

A 401 Unauthorized means the credential is missing or invalid. A 403 Forbidden means the credential is valid but the action is not allowed. That distinction saves debugging time.

Be careful storing JWTs in localStorage. Any XSS bug lets an attacker read them. HttpOnly cookies are harder for script to steal, though they bring their own CSRF concerns.