Interface Authentication: Core Differences Between Session/Cookie and JWT

Recommended Feeds

小众软件

博

爱范儿

量子位

博客园 - 锐洋智能

Eclipse IDE for Enterprise Find/Replace 窗口可以"停驻" 安装 SDelete 方式 SDelete 的核心作用，不是 “删文件”，而是 “把你已经删掉的文件，彻底从磁盘上抹干净”，同时帮你把虚拟机里的 “空闲空间” 变成连续的、可被回收的状态。 windows 10 启动就运行了一个批处理文件在什么地方修改？启动项中？让 Spring Framework7.0.7 支持 velocity Java 9+ 开启了模块化安全限制，不允许 Ignite 直接访问底层内存地址，导致 Ignite 启动失败 Spring 5.x + 老项目的 JWT 拦截器 + 自动续期下是针对 RedisSessionManager 的 Tomcat context.xml 配置示例，覆盖基础单机 Redis、带密码 / 指定库、Redis 哨兵集群、自定义序列化 / 持久化策略等常见场景 Redis-8.6.3-Windows-x64-cygwin 与 Redis-8.6.3-Windows-x64-msys2 有什么不一样？ commons-fileupload2 M4 升级 M5 报错解决方案阿里云的网络安全策略 ip 地址详细说明 Paralithic、 QLExpress、AviatorScript、exp4j 性能对比一下 java 序列化影响（重要！） paralithic 与 Aviator 表达式那一个更快券商接受委托的完整时间线 jQuery 4.0 移除了许多已废弃的方法和特性 xheditor插件无限递归错误解决方法 jedis-7.1.0.jar 升级至 jedis-7.2.0.jar 就提示：The type JedisPoolConfig is deprecated The type JedisPooled is deprecated Spring 从 5.x 到 6.x 和 7.x 区别 js 原生剪切板复制功能安装 Microsoft Visual C++ 运行时 Java与Python进程通信优化方案 Autocomplete | jQuery UI 同一面页定义不同的 .ui-autocomplete Quartz的misfire处理策略设置不当导致Job在应用启动时立即执行。 mysql-connector-j-9.5.0.jar BUG 推荐几款好用的CSS在线压缩工具 CSS 变量定义及引用 TLS virtual host [_default_], certificate type [RSA] configured from keystore [d:/reyo/jks/localhost.jks] using alias [tomcat] with trust store [null] okhttp5.x 需要在请求级别控制是否使用重试拦截器，而不是在客户端级别 Apache Commons FileUpload 1.x 与 2.x 的主要区别

Interface Authentication: Core Differences Between Session/Cookie and JWT

锐洋智能 · 2026-05-27 · via 博客园 - 锐洋智能

Interface Authentication: Core Differences Between Session/Cookie and JWT

You are absolutely right: Traditional web projects use Session/Cookie, while backend-frontend separated interface projects (RESTful APIs) must use JWT The core reason is the architecture has changed — traditionally, the server rendered pages, now it is frontend independent, interfaces stateless.

I will explain the differences between the two in the most popular and core way:

I. First understand: Why traditional interfaces can't use Session?

1. How Session Works (Stateful)

Browser Login → ServerGenerates Session and Stores It in Memory / Database
Server Returns a SessionID That Exists in Cookie
Next Request → Browser Automatically Carries Cookie → Server Checks Session to Confirm Identity

2. Fatal Flaws of Session (Not Suitable for APIs)

Strongly Dependent on Cookie: Limited by Cross-Domain, Mini Programs, Apps, Third-Party Calls
Server Must Store State：Distributed / Multi-server Session Sharing (Redis Synchronization)
is not friendly for frontend-backend separation ：Frontend is purely client-side, not relying on browsers to automatically carry cookies

Therefore: Interface authentication must discard the "server-side state storage" approach → JWT emerges

II. What is JWT? (Stateless)

JWT = JSON Web Token

In a nutshell: Encrypt user identity information into a string and store it on the client side, with the server not storing any login state .

Workflow:

Successful login → Server issues JWT using a secret key (Does not store any data)
Frontend stores JWT locally (localStorage / mini program cache)
Every time requesting an API → Frontend manually places JWT in the request header
Backend only uses a key to verify if the JWT is valid , no need to query the database

III. Core Differences Between Session / Cookie and JWT (Understand with a table)

Table

Comparison Dimension	Session / Cookie	JWT
Storage Location	Server-side storage, client only stores ID	All exist on the client, zero storage on the server
State	Stateful（Server needs to check session）	Stateless（Stateless, interface naturally supports distributed）
Cross-domain / Cross-end	Poor（Relies on Cookies, large cross-domain restrictions）	Extremely strong（Supports Web, mini programs, App, third-party interfaces）
Distributed deployment	Troublesome（Requires session sharing）	Extremely Simple（Multiple servers use the same key for verification）
Request Method	Browser automatically carries Cookies	FrontendManually transmitted（Request headers / Parameters）
Security Features	Vulnerable to CSRF attacks	No CSRF risk
Applicable Scenarios	Traditional websites, server-side rendering	Frontend-backend separation, RESTful API, microservices

Four, the most critical 3 fundamental differences

1. Stateless (most core)

Session: The server must remember that you are logged in (stateful)
JWTThe server doesn't remember anyone, only recognizes tokens (stateless)The interface architecture must be stateless, so JWT is the standard

2. Where is the data

Session: Exist on server
JWT: ExistsClient in their own hands

3. Scalability

Session: The more servers, the more trouble.
JWT:Add servers freely, no need to change the code

5. Simple summary: Why use JWT for the interface?

Does not rely on Cookie, supports cross-domain, mini programs, App
Server does not store login status, can be scaled freely for distributed / cluster
Standard and general, all front-end and back-end separated architectures use it
Secure and controllable, can be set to expire, can be encrypted, can prevent tampering

Summary

Session/Cookie: Suitable for traditional websites, server stores state, relies on browsers
JWT：Suitable for interface authentication , stateless, cross-platform, and friendly to distributed systems

You can simply remember:

Use Session for websites, use JWT for interfaces; stateful use Session, stateless use JWT.

<!-- JWT 工具：jjwt，Spring5 兼容 -->
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.5</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-impl</artifactId>
    <version>0.11.5</version>
    <scope>runtime</scope>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-jackson</artifactId>
    <version>0.11.5</version>
    <scope>runtime</scope>
</dependency>

This content is automatically aggregated by InertiaRSS (RSS Reader) for reading reference only. Original from — Copyright belongs to the original author.