慣性聚合 関心のあるブログ、ニュース、テクノロジーを効率的に追跡
原文を読む 慣性聚合で開く

おすすめ購読元

小众软件
小众软件
博客园 - 叶小钗
有赞技术团队
有赞技术团队
大猫的无限游戏
大猫的无限游戏
博客园_首页
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
L
LangChain Blog
Hugging Face - Blog
Hugging Face - Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
aimingoo的专栏
aimingoo的专栏
Blog — PlanetScale
Blog — PlanetScale
爱范儿
爱范儿
T
Tailwind CSS Blog
Jina AI
Jina AI
量子位
Stack Overflow Blog
Stack Overflow Blog
人人都是产品经理
人人都是产品经理
J
Java Code Geeks
V
Visual Studio Blog
月光博客
月光博客

博客园 - 锐洋智能

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 的主要区别
インターフェース認証:セッション/クッキーとJWTの核心的な違い
锐洋智能 · 2026-05-27 · via 博客园 - 锐洋智能

インターフェース認証:セッション/クッキーとJWTの核心的な違い

あなたの言う通りです:従来のWebプロジェクトではセッション/クッキーを使用し、フロントエンドとバックエンドが分離されたインターフェースプロジェクト(RESTful API)ではJWTを使用する必要があります。核心的な理由はアーキテクチャが変わったから——従来はサーバーサイドレンダリングのページでしたが、現在はフロントエンドが独立し、インターフェースが状態レスです。

私は最も一般的で核心的な方法で、両者の違いを明確に説明します:


一、まず理解する:なぜ従来のインターフェースではセッションは使えないのか?

セッションの動作原理(状態を持つ場合)

  1. ブラウザのログイン → サーバーセッションを生成しメモリ/データベースに保存
  2. サーバーはSessionID存在するCookieを返す
  3. 次のリクエスト → ブラウザが自動的にCookieを送信 → サーバーがセッションを検索して認証

2. セッションの致命的な欠点(インターフェースに適さない)

  • 強くCookieに依存:クロスドメイン、小程序、アプリ、サードパーティの呼び出しに制限
  • サーバーは状態を保存しなければならない:分散型 / 複数サーバーでセッション共有(Redis 同期)
  • の前後でフロントエンドとバックエンドの分離が不親切:フロントエンドは純粋なクライアントで、ブラウザが自動的に Cookie を持ってこない

したがって:インターフェース認証は「サーバーで状態を保存する」方法を捨てる必要がある → JWT が登場


二、JWT とは?(状態なし)

JWT = JSON Web Token

一言で言えば:ユーザー情報を暗号化して文字列にし、クライアントに保存し、サーバーはログイン状態を一切保存しない

動作フロー:

  1. ログイン成功 → サーバーがキーで JWT を発行(データを一切保存しない)
  2. フロントエンドはJWTをローカルに保存(localStorage / 小程序キャッシュ)
  3. 各リクエスト → フロントエンドJWTをリクエストヘッダーに手動で追加
  4. サーバーサイドは鍵を使ってJWTの合法性を検証のみ、データベース検索は不要

3. Session / CookieとJWTの核心的な違い(1枚の表で理解)

比較の维度Session / CookieJWT
保存場所 サーバー側にデータを保存し、クライアント側にはIDのみを保存 すべてのデータがクライアント側に存在、サーバー側はゼロストア
状態 状態あり(サーバーがセッションを検索する必要がある) 状態なし(Stateless、インターフェースが自然に分散処理をサポート)
クロスドメイン / クロスエンドポイント 悪い(Cookieに依存、クロスドメイン制限が大きい) 非常に強(Web、小程序、アプリ、サードパーティインターフェースをサポート)
分散デプロイメント 面倒(セッション共有が必要) 非常に簡単(複数のサーバーが同じキーで検証)
リクエスト方法 ブラウザが自動的に Cookie を持ってくる フロントエンド手動で送信(リクエストヘッダー / パラメータ)
セキュリティの特徴 CSRF 攻撃に容易にさらされる CSRF のリスクがない
適用シーン 従来のウェブサイト、サーバーサイドレンダリング フロントエンドとバックエンドの分離、RESTful API、マイクロサービス

四、最も重要な 3 つの本質的な違い

状態の有無(最も核心)

  • セッションサーバーはあなたがログインしたことを覚えておく必要があります(状態を持つ)
  • JWTサーバーは誰も覚えない。トークンのみを認識する(ステートレス)インターフェースのアーキテクチャはステートレスである必要があり、そのためJWTは標準です

2. データはどこにありますか

  • セッション:サーバーに存在します
  • JWTは存在しますクライアント側で自分で持っている

3. 拡張性

  • セッション:サーバーが多いほど面倒になる
  • JWT:サーバーを好きに追加し、コードを変更する必要が全くない

五、簡単なまとめ:なぜインターフェースにJWTを使用するのか

  1. Cookieに依存しない、クロスドメイン、小程序、アプリともにサポート
  2. サーバーでログイン状態を保存しない、分散/クラスタリングで自由に拡張可能
  3. 標準的で一般的、すべてのフロントエンド/バックエンド分離アーキテクチャで使用
  4. セキュアで管理可能、有効期限を設定したり、暗号化したり、改ざん防止が可能

まとめ

  • Session/Cookie:伝統的なウェブサイトに適しており、サーバーで状態を保存し、ブラウザに依存
  • JWTインターフェース認証に適しており、状態レス、クロスデバイス、分散システムに親和性が高い

簡単に覚えておくと:

ウェブサイトにはSessionを使い、インターフェースにはJWTを使う;状態がある場合はSessionを使い、状態がない場合は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>