Comprehensive Guide to JWT Authentication: Concepts, Advantages, Security Issues, and Solutions

JWT Advantages

Compared with traditional session authentication, using JWT for identity verification offers four main advantages.

Stateless

JWT itself contains all information required for authentication, so the server does not need to store session data, which improves system availability, scalability and reduces server load.

However, the stateless nature also brings the biggest drawback: lack of control. For example, a JWT cannot be revoked or have its permissions changed until it expires, and a logout operation does not immediately invalidate the token unless additional backend logic is added.

Effective CSRF Prevention

Because JWT is usually stored in localStorage and sent in request headers, it is not automatically attached to cross‑site requests that rely on cookies. Therefore, CSRF attacks that exploit the browser’s automatic cookie submission are avoided.

In contrast, session authentication relies on the SessionID cookie, which is sent with every request, allowing an attacker to forge requests if the user is tricked into clicking a malicious link.

Suitable for Mobile Applications

Session authentication requires server‑side storage and a cookie that holds the SessionId , which is inconvenient for mobile clients. JWT can be stored locally on any device and works across different programming languages.

Single‑Sign‑On Friendly

Since the token is kept on the client side, implementing SSO does not require sharing session data across servers or dealing with cross‑domain cookie issues.

Common JWT Issues and Solutions

Token Still Valid After Logout, Password Change, etc.

Because a JWT remains valid until its expiration, scenarios such as user logout, password change, role modification, account suspension, or forced logout cannot be handled by simply deleting a session record.

Four practical solutions are summarized:

Store JWT in an in‑memory database (e.g., Redis) – delete the token from Redis to revoke it, though this breaks the stateless principle.

Blacklist mechanism – maintain a blacklist of revoked tokens in Redis and check each request against it.

Rotate secret keys per user – change the signing secret to invalidate existing tokens, but this adds complexity in distributed environments.

Use short‑lived tokens with frequent rotation – reduces the window of misuse but requires users to log in more often.

A convenient approach is to sign the JWT with a hash of the user’s password; when the password changes, previously issued tokens become invalid automatically.

JWT Refresh Strategies

Because JWTs are usually given a relatively short expiration time, a mechanism is needed to obtain a new token without forcing the user to log in again.

Four common patterns are described:

Session‑like sliding expiration – when a token is close to expiry, the server issues a new one.

Issue a new token on every request – simple but adds overhead.

Set token expiry to a fixed time (e.g., midnight) – a compromise for low‑security scenarios.

Use a pair of tokens – an accessJWT with short life (e.g., 30 minutes) and a refreshJWT with longer life (e.g., 1 day). When the access token expires, the client sends the refresh token to obtain a new access token.

The dual‑token approach requires client cooperation, handling of simultaneous logout for both tokens, and a short window where the access token may be unavailable.

Summary

JWT’s stateless nature is a major advantage, but practical projects often need to store token information or adopt auxiliary mechanisms to achieve revocation, logout, and token renewal.

JWT is not a silver bullet; its drawbacks must be weighed against project requirements, and alternative schemes such as simple random tokens combined with Redis should also be considered.

<a src="http://www.mybank.com/Transfer?bankId=11&money=10000">Scientific Investment, Annual Return Over 10,000%</a>

@Component
@Order(Ordered.HIGHEST_PRECEDENCE)
public class XSSFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain) throws IOException, ServletException {
        XSSRequestWrapper wrappedRequest = new XSSRequestWrapper((HttpServletRequest) request);
        chain.doFilter(wrappedRequest, response);
    }
    // other methods
}