Published on

Authentication in Web 1 - Session and Token

Authors

@Author: Garfield Zhu

Web Application Authentication (1) - Session and Token

Typically in Web world, the authentication is very first step for the user to access the resources and the crutial point for guarding the data and the site security.

To highlight the keypoints to be considered when implementing auth in web server, I'll talk about in a series of articles.

At the very beginning, let's start from the most well known and basic point: token and session.

Session

How Sessions Work

User Logs In: The client sends login credentials (e.g., username and password) to the server.

Session Creation: If authentication is successful, the server generates a unique session identifier (Session ID) and associates it with the user information in memory or a persistent store (e.g., database, Redis).

Session Tracking: The server sends the session ID back to the client, typically stored in a cookie.

Subsequent Requests: The client includes the session ID in each request. The server verifies the session ID to retrieve the user’s state.

Cookies are the primary method to store session identifiers on the client side. These small data packets are automatically sent with each HTTP request to the server.

When a new request is made, the browser usually sends previously stored cookies for the current domain back to the server within a Cookie HTTP header, which makes it natural to bring the session information together with the cookies.

Setting a Cookie Example (HTTP Response Header):

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Strict

  • HttpOnly: Prevents JavaScript from accessing the cookie, mitigating XSS attacks.

  • Secure: Ensures the cookie is only sent over HTTPS.

  • SameSite: Controls whether the cookie is sent with cross-site requests ("Strict" prevents cross-site transmission).

Session Storage

Sessions need to be stored on the server side for validation. Common storage approaches include:

  1. In-Memory: Fast but volatile; best for small-scale applications (e.g., using HttpSession in Spring Boot).

  2. Database: Persistent and reliable across service restarts, ideal for larger systems.

  3. Distributed Cache: For horizontally scaled applications, use Redis or Memcached to store sessions.

Session Expiration and Security

  1. Expiration: Set a reasonable expiration time (e.g., 30 minutes of inactivity) and periodically clear expired sessions.

  2. Regenerate IDs: Refresh the session ID on sensitive operations (e.g., after login) to prevent session fixation.

  3. Secure Cookies: Always use HttpOnly, Secure, and SameSite attributes to reduce the risk of attacks.

Token

The tokens is any long, random string representing some unique things, stored on the server and

  • The tokens should be generally long and unique, 128~256 bits should be good. e.g. UUID.
  • Usually used for authentication and verification. e.g. session ID, access token.
  • Tokens must be generated using a cryptographically secure random generator. Standard Math libraries, like Math.random methods in Java and JS are bad for security. Use crypto methods instead. e.g. "crypto/rand" in golang, Crypto.randomUUID() in JS.
  • Tokens should be stored after a hash, like SHA-256. It makes that the token will not be really exposed from storage, but just be verified by hashed values.

For example, the DB table for storing the tokens of user sessions should:

  1. make the hased token as a non-null unique string;
  2. each token represents a user session, which refers to the user as a foreign, to query the user privilege/access.
  3. each token has an expiration time for extra security;
CREATE TABLE token (
  token_key STRING NOT NULL UNIQUE,
  user_id INTEGER NOT NULL,
  expires_at INTEGER NOT NULL,

  PRIMARY KEY (token_key),
  FOREIGN KEY (user_id) REFERENCES user(id)
)

JWT

As we discussed in the session secion, the session is generally persisted in DB or a persistent layer. It is stateful and makes the authentication relies on the persistency.

To have a stateless and decentralized authentication token, we have JWT, AKA JSON Web Tokens, which is also a token, but contains information.

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

JWT Data Structure

This is what is JWT token looks: jwt sample

It actually has 3 parts, and separated by a dot .. Thus, its pattern is like {Header}.{Payload}.{Signature}. Each part is encoded by Base64URL, which is a little bit different from typical Base64, for supporting use the JWT in HTTP request query parameters.

  • First part is Header header The header part includes:

    • alg: The algorithm for signature. By default HS256 (HMAC SHA256).
    • typ: The type of the token. Always be JWT as a JWT.

  • Middle part is Payload header Put the real payload with necessary information, which is equivalent to the session persistented on the server. Using JWT, the server does not need to query the session data from DB but just decoded them from the JWT passed by the client.

    In RFC 7519, it claims 7 registerd claim names in JWT payload. They are not mandatory to be used. Any custom fields can be used in the payload, but the names should be short because a core goal of JWTs is for the representation to be compact.

  • Last part is Signature header The signature part actually signs the above 2 parts. The server maintains a secret key for signature and never exposes the any external points. Once a user signs in, the server generates the JWT and use the secret key for signing the token by the alg. When processing every requests with JWT, the server will validate the payload by the signature to avoid any malicious tampering in the payload.

Pros and cons

  • 👍 Stateless. Reduce the IO cost for getting session info on server.
  • 👍 Immutable payload. No one can write or modify the data to JWT expcept the server.
  • 👍 Can be encrypted again for higher security.
  • 👎 Hard to abort or revoke a signed JWT postively before it reaches it expiration.
  • 👎 Authorities info could leak once the JWT is leaked.

Usage and scenarios

JWTs are generally used in Web and Mobile application, because it's lightweight and stateless.

  • Auth login Within the auth login APIs, the server should generate the JWT and typically send it in response body.
  • Request with JWT For each requests need a authorized user, the client is recommended to carry the JWT in the header: Auhtorization: Bearer <token> This is the most common practice. Also, a special customized header like X-Authorization-Token is also a deal. Though cookie can make it being carried automatically, it is not recommended for JWT considering CORS.
  • Expiration and protocol
    • Recommend to use a short expiration. And use a refresh token together.
    • Always use HTTPS.

References

CSRF token

This topic deserves a standalone page, I think. Let's move it to Web Application Authentication (4) - CSRF.

Reference

Discuss on Twitter • View on GitHub