JWT vs Session Authentication

Different websites or web applications often require users to provide specific credentials to access their content. Users would typically follow certain steps, such as signing up, logging in with peculiar credentials to access the website or application’s content.

This process is referred to as authentication, and it is the act of identifying the user's legitimacy.

Typically, when requests are made to a server via HTTP, each request is independent and does not contain information about previous requests; in other words, HTTP is stateless.

This lack of continuity means every time a user wants to access resources within a website or application, the user would have to always provide the login credentials, which can be tedious.

However, some methods allow the server to trust the request sent by an authenticated user over the internet and maintain an authentication state across multiple requests. These include session-based authentication and JWT (JSON Web Token) authentication.

Before we discuss JWT and Session-based authentication, let’s go through a brief overview of authentication and its importance in the development of web applications.

TL;DR:
Both Session Authentication and JWT (JSON Web Token) Authentication let users stay logged in without re-entering credentials, but they differ in how they store and verify data. Session Authentication saves session details on the server and uses cookies to identify users—easy to manage but harder to scale. JWT Authentication stores user data directly in an encrypted token on the client side, making it stateless and faster but harder to revoke before expiry. Use sessions for monolithic apps and JWTs for APIs or distributed systems needing cross-service authentication.

In the context of web development, authentication is simply a process of verifying if a user is who they say they are, essentially confirming the identity of the user.

You can think of authentication as a contract or agreement that binds a user to a website or application, allowing them access based on their verified identity.

There are different forms of authentication, such as;

• Password-based authentication
• One-time password authentication
• Biometric authentication (use of human features like a thumbprint, retina scan, etc.)
• A combination of two or more types of authentications, e.g. Password and OTP

The most common form of authentication method is providing a username and password. When a user submits these credentials, they are compared with the credentials stored on the application server, which the user provided during the sign-up phase. If the credentials are valid, the user is granted access.

Authentication and its Importance in Web Development

There are various reasons why authentication is crucial in web development, including;

• Protects confidential data
• Protects web applications from unauthorized access
• Builds trust and reputation between users and systems/applications
• Keep track of users' behavior.

There are various methods involved in authenticating web applications; examples include;

• Session-based authentication
• Token-based authentication (JWT-)
• Third-party authentication (OAuth, API token)
• SAML (Security Assertion Markup Language)
• OpenID (Standard and decentralized authentication protocol)

The two main methods of user authentication in web development are session authentication and JWT (JSON Web Token Authentication).

When a user provides the necessary credentials required to log into a website, session authentication can be used to manage the authentication state.

The server creates a persistent record that represents the session, and this record contains a unique identifier created for the user. The record is stored in the database or file system and returned to the browser in the form of a cookie. The browser then stores the record as a cookie, allowing the server to recognize the user on subsequent requests.

Each following HTTP request from the browser sent to the server contains the session cookie. The server then uses this cookie to look up the session record and verify that it is valid and then ensures the user remains authenticated during every request.

Let’s break this down;

• The server receives an initial login request sent by the user via login credentials.

• The server checks that login credentials are accurate against stored information in the database.

• The server creates a new session and stores it (typically in a database or memory cache), the data might include data ID, expiration time and other metadata.

• The server sends a response with a unique session ID in the form of a cookie.

• The user receives the server's response along with the session ID and saves it in the cookie.

• On subsequent requests, the client sends a session ID cookie with each request

• The server receives the request with the cookie, identifies and verifies that the corresponding session data is in the session store, and uses the data to authenticate and process the request.

This process occurs for subsequent HTTP requests sent from the client to the server. As long as the user is logged in, the server knows which user is making a request instead of making the user re-authenticate their credentials.

The session ID is destroyed on both the client and the server side when the client logs out. This means that once the session is terminated, the user is no longer authenticated, preventing unauthorized access to the account after the user has logged out.

Benefits of Session Authentication

• Revoking sessions can be done easily since the session is stored on the server. The server can invalidate the session at any time, effectively ending the users’ authentication.

• Session authentication is easy to use if you're developing a web-based application because cookies are supported by browsers on the client side.

• Session cookies do not require large storage, making it efficient for storage on the client side.

• The server controls sessions, therefore, it can implement security measures such as session timeout or IP address validation.

Limitations of Session Authentication

• In large-scale projects, session-based authentication can introduce latency issues because it requires interaction with a centralized store such as the database. Also, if there's a heavy load, it affects the performance of the application.

• In a distributed system where an application runs on multiple servers, the servers need access to the same session data. Using a centralized session store that all servers can access may add latency and complexity to each request because the server needs to make a separate trip to the session store.

• If session IDs are not secured properly, they are vulnerable to XSS attacks allowing attackers the ability to impersonate users.

JSON Web Token [JWT] is a means of sharing information between two entities, for example, between a web application and a server.

When a user provides the credentials for authentication in JSON Web Token [JWT] authentication, the credentials and authentication tokens are transmitted between the client and server in JSON format. This provides a simple and secure way to verify user identity across several requests.

This also means that once a user logs in, their credentials are verified by the server. The server then generates a JWT and sends it to the client. The JWT contains the user ID, user information permission, expiration date, and so on. Every request the client makes subsequently to the server would include the JWT, which authenticates the user and grants them continuous access as long as they are logged in.

The JWT consists of three components, which are:

• Header: This contains information about the type of [token]({entry:blog/token-payment online}) (JWT) along with the signing and decoding algorithm.

• Payload: This contains the claims, which is the user’s information, for example; ID, permissions, and other important information.

• Signature: This contains the signature created by the server when it creates the JWT after a successful login

The server combines the header and payload and signs with a secret key, only the server knows. This signature is added to the JWT before it is sent to the client.

Let’s break this down:

• The server receives the initial login request sent by the user via login credentials.

• The server checks that the login credentials are accurate against stored information in the database.

• The server generates a JWT and sends the response back with a JWT (the server takes the header and payload combines them and signs a secret key; the signature ensures the integrity of the JWT to prevent tampering).

• The server sends JWT to the client in the response body.

• The client receives JWT and stores it in a cookie or local storage (which is usually in the authorization header)

• On subsequent requests, the clients send JWT in the request headers

• The server receives the request with the JWT and verifies the JWT signature to check validity.

• If it's valid, the server trusts the data in the token and uses it for authentication and authorization.

The server uses several algorithms to sign JWTs (HMAC, RSA, and ECDSA)

• Hash-Based Message Authentication code (HMAC): This is a symmetric signing technique wherein the secret key used in signing a token is the same key used in verifying the token. It is simpler and more efficient but requires sharing a secret key with a service that needs to verify the token, which can pose a security issue.

• Rivest Shamir Adleman (RSA) and Elliptic Curve Digital Signature Algorithm (ECDSA): These are asymmetric singing techniques. They use a private key to sign and a public key to verify a token. This is more secure because the private key is kept a secret and only used for signing and services can verify the token using the public key. This is also more complex and adds more computational overhead compared to HMAC.

Choosing any of these methods depends on the system architecture and security requirements. HMAC is preferred if your application is monolithic, while RSA or ECDSA is preferred because they are more secure, especially if you have microservices or need to share JWTs with a third-party service.

### Benefits of JSON Web Token

There are several benefits of JWT which include;

• JWT utilizes signing and encryption, which makes it less vulnerable to XSS (cross-site scripting) attacks.

• JWT is generated on the server but stored only on the client; the client then submits JWT with every request. This process saves database space.

• JWT doesn't store the session state; all necessary data is contained within the token stored on the client, which makes it stateless

Limitation of JSON Web Token

Several limitations with using JWT include:

• JWT has a contained nature and stateless verification process, which makes it difficult to revoke a JWT before it expires naturally. This means revoking a user cannot be implemented quickly.

• JWT is much faster in performing authorization, however, it can become large if it carries large user data, which can lead to high traffic in the network.

• If the JWT secret key is compromised, attackers can create valid tokens and impersonate users.

• If a JWT contains many claims, its size can increase rapidly, which may lead to load balancer blocks being requested due to oversized headers.

JWT and Session authentication allow seamless interaction with websites or web applications. They can be applied differently as they both have applications they work best for. For instance, JWT authentication is a good choice if you need a stateless architecture server that does not store information about the state client during a request.

Session authentication is a good choice if you need a stateful application that allows the server to manage the user authentication state during user interaction with an application.