












あなたの言う通りです:従来のWebプロジェクトではセッション/クッキーを使用し、フロントエンドとバックエンドが分離されたインターフェースプロジェクト(RESTful API)ではJWTを使用する必要があります。核心的な理由はアーキテクチャが変わったから——従来はサーバーサイドレンダリングのページでしたが、現在はフロントエンドが独立し、インターフェースが状態レスです。
私は最も一般的で核心的な方法で、両者の違いを明確に説明します:
SessionID存在するCookieを返す
したがって:インターフェース認証は「サーバーで状態を保存する」方法を捨てる必要がある → JWT が登場
JWT = JSON Web Token
一言で言えば:ユーザー情報を暗号化して文字列にし、クライアントに保存し、サーバーはログイン状態を一切保存しない。
動作フロー:
表
| 比較の维度 | Session / Cookie | JWT |
|---|---|---|
| 保存場所 | サーバー側にデータを保存し、クライアント側にはIDのみを保存 | すべてのデータがクライアント側に存在、サーバー側はゼロストア |
| 状態 | 状態あり(サーバーがセッションを検索する必要がある) | 状態なし(Stateless、インターフェースが自然に分散処理をサポート) |
| クロスドメイン / クロスエンドポイント | 悪い(Cookieに依存、クロスドメイン制限が大きい) | 非常に強(Web、小程序、アプリ、サードパーティインターフェースをサポート) |
| 分散デプロイメント | 面倒(セッション共有が必要) | 非常に簡単(複数のサーバーが同じキーで検証) |
| リクエスト方法 | ブラウザが自動的に Cookie を持ってくる | フロントエンド手動で送信(リクエストヘッダー / パラメータ) |
| セキュリティの特徴 | CSRF 攻撃に容易にさらされる | CSRF のリスクがない |
| 適用シーン | 従来のウェブサイト、サーバーサイドレンダリング | フロントエンドとバックエンドの分離、RESTful API、マイクロサービス |
簡単に覚えておくと:
ウェブサイトには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>
このコンテンツは慣性聚合(RSSリーダー)によって自動集約されています。参考としてご覧ください。 原文出典 — 著作権は原著者に帰属します。