Back to Portfolio

Token vs Session Authentication

Authentication is the process of verifying if a user is who they are claiming to be. The most common way to verify a user is by using a password only the user would know, or by additionally having a third party verify their identity, also known as 2-factor authentication. So, when the user initially sends their username and password to the server, essentially 2 things happen: the server will receive their request and verify their identity based on if the username and password match its records, and if they do, the server establishes an authenticated session or issues a token. Only then will the client (or application) store some form of proof of authentication, in the form of a cookie or token, so that in subsequent requests it can be sent to the server rather than prompt the user to keep sending their credentials.

What we want to discuss, are the different ways the backend server handles checking the authentication, the types and their trade-offs in terms of security and performance

Stateless vs Stateful Authentication

These 2 methods are Stateful and Stateless

Stateful authentication simply means that once you've logged in the server keeps track of a the current authentication status and keeps track of the users that are currently logged in until log out. The users' statuses are usually stored server-side (often in a shared store such as Redis or a database), so when a user makes a request from his browser, the cookie including his authentication details is stored client-side and will be sent alongside it. The server will then check the database to see if the user is A. logged in (active) or logged out (inactive), and B. and if the sent data matches that of the active session details Alternatively, the application can handle the authentication in a stateless way, meaning the server doesn't track the user's state. The data being sent by the user alone to verify their identity is enough for the server to validate them.

These approaches have their trade-offs but in general …

So, now that we know what the 2 types of authentications are, lets delve into the tools and protocols that an application uses to complete the process of authentication.

Authentication Methods

There are many concrete protocols and techniques wildly used globally to authenticate users like:

But the ones we are going to be focusing on are:

Session Authentication

A session is a server-side record representing a user's authenticated state. This record exists until the user's authentication expires whether by logging out, or set expiration rules session authentication is where once a user logs in, the server stores information about the user's authentication identity on a db, making it stateful. This data is then returned to the user in the form of a cookie and in subsequent requests the generated cookie is sent alongside them.

So, let's say for example, a user with a private twitter wants to see their posts, they enter their credentials and login, once the server verifies the credentials, it will generate a session record and store it server-side which may look like this:

{
  "session_id": "7f9c2e4a9b...",
  "user_id": 12345,
  "username": "alice",
  "authenticated": true,
  "roles": ["USER"],
  "created_at": "2026-01-07T10:12:00Z"
}

The important value to note here is session_id, which will now be sent back to the client as a cookie. Cookie:

Set-Cookie: session_id=7f9c2e4a9b...;

The user now has their authentication information stored in a cookie. When the user opens their account to see their posts, a request is sent to the server containing that cookie. Cookie sent alongside request:

GET /my/private-posts
Cookie: session_id=7f9c2e4a9b...

The server logic will see that the data is private and can only be accessed by a specific user (which it tracks using user_id). It will see if the session id sent by the client:

Finally, the server responds with the requested resources.

Advantages:

Limitations:

Token Authentication

Tokens (such as JWTs) are cryptographically signed data that is stored by the user and sent alongside requests so servers can verify their authenticity A good analogy is to think of tokens as a ticket to a movie resource. Your ticket gains you access to your movie and no other, so when the cashier hands you the ticket and you hand it to the theatre guy, he doesn't have to authenticate that you are the buyer – he just validates your ticket.

In other words, when a user logs in using their credentials, the server will verify the credentials are returned a signed token. The client receives this token and stores it locally on the client side. The token is then placed in the "authorization header" of subsequent requests and all the server does is verify if the token is valid.

Typical web api token authentication request headers:

> GET /api_path HTTP/1.1
> Host: yourdomain.com
> Authorization: Bearer <AUTHGEAR_ACCESS_TOKEN>

Finally, if the user logs out of the application and the client deletes the token from local storage.

Advantages:

Limitations:

When to implement Session vs Token

There are practical decision rules engineers follow when deciding whether their service should handle authentication via session-based auth or token-based auth, session-based authentication is recommended when …

On the other hand, token-based authentication is recommended when …

Sources