Stateless Login Principle and Implementation Using JWT and RSA

Stateless Login Principle

Stateful services require the server to store client session information (e.g., Tomcat session), which increases server storage pressure, prevents horizontal scaling, and forces client requests to hit the same server.

What Is Stateful?

In a typical login scenario, after a user logs in, the server saves the user’s information in a session and returns a cookie that links the client to that session for subsequent requests.

Drawbacks of Stateful Authentication

Server stores large amounts of data, increasing load.

Server‑side state hinders horizontal scaling.

Client requests depend on a specific server instance.

What Is Stateless?

Microservice clusters expose RESTful APIs, and REST requires services to be stateless: the server does not retain any client information, and each request must contain self‑describing data to identify the client.

Benefits of Stateless Design

Client requests are independent of server state; any instance can handle successive requests.

Server clusters are transparent to clients.

Servers can be migrated or scaled arbitrarily.

Reduced storage pressure on the server.

How to Achieve Stateless Login

Stateless login flow:

When the client first accesses the service, the server authenticates the user (login).

After successful authentication, the server encrypts the user information into a token and returns it to the client.

For subsequent requests, the client includes the token.

The server decrypts the token and validates its integrity.

The critical point is the security of the token.

We use JWT combined with RSA asymmetric encryption.

JWT

Overview

JWT (JSON Web Token) is a lightweight JSON‑based standard for authorization and authentication, enabling stateless, distributed web application authorization.

Official site: https://jwt.io

Java client library: https://github.com/jwtk/jjwt

Data Structure

JWT consists of three parts:

Header : declares the token type (JWT) and the signing algorithm (customizable). This part is Base64‑encoded.

Payload : contains the actual data, such as user identity (do not store sensitive data) and claims like issuance time, expiration, issuer. This part is also Base64‑encoded.

Signature : generated by signing the Base64‑encoded header and payload with a secret key (or private key). It ensures data integrity and authenticity.

The resulting token format is header.payload.signature .

JWT Interaction Flow

1. User logs in. 2. Server authenticates and creates a JWT signed with a secret/key. 3. Server returns the JWT to the client. 4. Client includes the JWT in every subsequent request. 5. Server verifies the JWT signature (using the public key if RSA) and extracts user information from the payload. 6. Server processes the request and returns the response.

Because the JWT already carries the user’s identity, the server does not need to store session data or query a database, fully complying with REST’s stateless principle.

Asymmetric Encryption (RSA)

Asymmetric encryption uses a pair of keys: a private key kept secret and a public key distributed to trusted clients. RSA can be used to sign JWTs, providing strong security while allowing verification with the public key.

RSA in the Authentication Flow

Generate RSA public/private key pair; private key stored in the authorization center, public key deployed to Zuul and all microservices.

User logs in.

Authorization center validates credentials and signs the JWT with the private key.

JWT is returned to the user.

User includes JWT in subsequent requests.

Zuul verifies the JWT using the public key and forwards the request.

Microservices also verify and parse the JWT locally, eliminating the need to call the authorization center for each request.

This reduces network overhead and improves system efficiency while maintaining secure, stateless authentication.

(End)