Authentication done right: JWT, sessions, and OAuth explained — Like a Marvel superhero assembling the team

The Beginning (The Why)

The author recalls their first attempt at implementing login functionality for a side project. They followed a tutorial that suggested storing a token in localStorage and called it a day. A week later, they received an email from a user complaining about logout issues and unauthorized access. This prompted a deep dive into the differences between sessions, JSON Web Tokens (JWT), and OAuth, with the goal of understanding when to use each approach effectively.

The Revelation (The Insight)

The author explains that sessions are the traditional server-side approach. When a user logs in, the server generates a unique session ID, stores it in a database or cache like Redis or Memcached, and sends it back to the browser as an HttpOnly cookie. The browser automatically includes this cookie with every request, allowing the server to retrieve the associated user data.

Sessions are favored for their security, as the secret is never exposed to the client, and revoking a session is straightforward by deleting the corresponding entry from the store. However, sessions can be cumbersome for horizontally scalable applications, as each server instance needs access to a shared session store, and each request requires a database lookup, which can introduce latency.

JSON Web Tokens (JWT) are introduced as a lightweight, stateless alternative. A JWT is a signed string containing claims about the user, such as their ID, roles, and expiration time. The server creates the token after verifying user credentials and sends it to the client, which includes it in the Authorization header or as a cookie on each request.

JWTs can embed user permissions directly, reducing the need for additional database queries. However, JWTs have their drawbacks; they are vulnerable to theft since the token lives on the client side, making revocation challenging once it's issued. The payload is not encrypted, so sensitive information should not be included, and the token size can add overhead to each request.

OAuth 2.0 is then described as an authorization framework rather than an authentication protocol. It enables third-party applications to gain limited access to user accounts without requiring passwords. OAuth 2.0, combined with OpenID Connect (OIDC), allows users to log in using trusted providers like Google or GitHub, granting apps only the necessary permissions.

This approach enhances security by avoiding password sharing and supports Single Sign-On (SSO) capabilities. However, OAuth involves complex redirect flows and requires careful management of client secrets and security measures against cross-site request forgery (CSRF). Often, OAuth is paired with JWTs or sessions to handle API authentication efficiently.

Code & Examples

The author provides practical code examples demonstrating common pitfalls and solutions for each method. For session-based authentication using Express and Redis, a common mistake is storing the session ID in a cookie without setting the HttpOnly flag, which allows JavaScript to access the cookie and potentially execute cross-site scripting (XSS) attacks. The correct approach is to use an HttpOnly cookie, ensuring that the session remains secure.

In the second example, JWT issuance using the jsonwebtoken library in Node.js is illustrated. A common error is embedding sensitive data like the user's password hash within the JWT payload, which is insecure since anyone intercepting the token can view the hash. The recommended practice is to keep the payload minimal, including only essential claims such as the user's ID and role. The server should then handle any additional data lookups as needed.