【WitSystem】詳解JWT在系統登錄過程中前端做了什么事，后端又做了什么事？

要理解 JWT（JSON Web Token）登錄流程中前端與后端的職責分工，需先明確 JWT 的核心定位：它是一種無狀態的身份認證令牌，用于替代傳統 Session 認證，解決跨服務、跨域登錄的問題。其流程本質是“后端生成令牌 → 前端存儲并攜帶令牌 → 后端驗證令牌”的閉環，以下分步驟拆解兩端的具體操作。

一、前置概念：JWT 的結構與作用

在講解流程前，需先明確 JWT 的組成（共 3 部分，用.分隔），這是理解后續驗證邏輯的基礎：

部分名稱作用
第一部分Header（頭部）聲明令牌類型（JWT）和簽名算法（如 HS256、RS256），Base64 編碼（可解碼）
第二部分Payload（載荷）存儲非敏感的用戶身份信息（如 userID、角色、過期時間 exp），Base64 編碼（可解碼）
第三部分Signature（簽名）用 Header 指定的算法，結合后端密鑰對前兩部分加密，確保令牌未被篡改

?? 關鍵提醒：Payload 是 Base64 編碼（不是加密），任何人都能解碼，因此絕對不能存密碼、手機號等敏感信息！

二、JWT 登錄完整流程：前端 + 后端分工

JWT 登錄流程分為 3 個核心階段：登錄請求階段、令牌存儲與攜帶階段、接口訪問驗證階段。兩端在每個階段的操作明確且互補，具體如下：

階段 1：登錄請求階段（用戶輸入賬號密碼，獲取 JWT）

這是流程的起點，目標是讓后端驗證用戶身份，并生成合法的 JWT 令牌返回給前端。

1.1 前端做什么？

核心動作：收集用戶信息 → 發送登錄請求 → 接收并暫存令牌

  1. 收集并校驗用戶輸入：
    • 通過登錄表單獲取用戶輸入的賬號（如手機號/郵箱）、密碼；
    • 前端做基礎合法性校驗（非空、格式驗證，如手機號是否符合 11 位規則），避免無效請求占用后端資源。
  2. 發送 POST 登錄請求：
    • 向后端登錄接口（如 /api/login）發送請求，請求體攜帶用戶信息（通常用 JSON 格式）；
    • 示例請求體：
      {"username": "zhangsan","password": "123456aA!"  // 實際項目中需加密（如 HTTPS + 前端簡單哈希），避免明文傳輸
}
  3. 接收后端響應并處理：
    • 若登錄失敗（如賬號密碼錯誤）：提示用戶“用戶名或密碼錯誤”，流程終止；
    • 若登錄成功：后端會返回 JWT 令牌（通常在響應體的 token 字段，或 Header 的 Authorization 字段），前端需暫存令牌（下一步會講持久化存儲），并跳轉至首頁/登錄后的頁面。
1.2 后端做什么？

核心動作：驗證用戶身份 → 生成 JWT 令牌 → 返回令牌

  1. 接收并驗證用戶身份：
    • 接收前端發送的賬號密碼，先對密碼進行解密（若前端加密）；
    • 從數據庫中查詢該賬號對應的記錄，對比加密后的密碼（后端存儲密碼必須用哈希算法加密，如 BCrypt，絕對不能存明文）；
    • 若賬號不存在或密碼不匹配，返回 401（Unauthorized）錯誤，附帶失敗信息。
  2. 生成 JWT 令牌：
    • 若身份驗證通過，構建 JWT 的 Payload（載荷），必須包含過期時間（exp）（如當前時間 + 2 小時，避免令牌永久有效），可選包含 userID、role（角色，用于權限控制）等非敏感信息；
    • 用 Header 中指定的算法（如 HS256），結合后端唯一密鑰（Secret Key） 對 Header + . + Payload 進行簽名，生成完整的 JWT 令牌；
      ?? 關鍵：后端密鑰必須安全存儲（如配置中心、環境變量），絕對不能硬編碼在代碼中，否則密鑰泄露會導致令牌被偽造！
  3. 返回令牌給前端：
    • 將生成的 JWT 令牌放在響應體中（如 { "code": 200, "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "msg": "登錄成功" }），或放在響應頭的 Authorization 字段（格式通常為 Bearer <token>）；
    • 返回 200（OK）狀態碼，完成登錄響應。

階段 2：令牌存儲與攜帶階段（前端持久化令牌，后續請求攜帶）

登錄成功后，前端需持久化存儲令牌（避免頁面刷新后令牌丟失），并在后續所有需要身份驗證的接口請求中主動攜帶令牌，讓后端識別用戶身份。

2.1 前端做什么？

核心動作：持久化存儲令牌 → 攔截請求并攜帶令牌 → 處理令牌過期

  1. 持久化存儲令牌：

    • 常用存儲方案對比（需根據項目需求選擇）：
      存儲方式優點缺點適用場景
      localStorage永久存儲（除非手動刪除）、容量大（5MB）易受 XSS 攻擊（腳本可讀取）非敏感場景，如普通網站
      sessionStorage會話級存儲（關閉標簽頁后刪除）易受 XSS 攻擊，頁面刷新不丟失臨時登錄，如敏感操作頁面
      Cookie可設置 HttpOnly（防 XSS）、Secure（僅 HTTPS）易受 CSRF 攻擊，容量小（4KB）高安全場景，如金融類應用
    • 最佳實踐：若用 Cookie 存儲，需開啟 HttpOnly（禁止前端 JS 讀取，防 XSS）、Secure（僅 HTTPS 傳輸）、SameSite=Strict（防 CSRF）；若用 localStorage，需配合前端 XSS 防護（如輸入過濾、CSP 策略）。

  2. 攔截請求并攜帶令牌：

    • 用前端請求庫（如 Axios、Fetch）的請求攔截器，對所有需要身份驗證的接口（如 /api/user/info、/api/order/list）自動添加令牌；
    • 攜帶格式：遵循后端約定，通常放在請求頭的 Authorization 字段，格式為 Bearer <token>（注意 Bearer 后有空格）；
      示例 Axios 攔截器代碼：
      // Axios 請求攔截器
axios.interceptors.request.use(config => {// 從 localStorage 中獲取令牌const token = localStorage.getItem('token');if (token) {// 給請求頭添加 Authorization 字段config.headers.Authorization = `Bearer ${token}`;}return config;
}, error => Promise.reject(error));

  3. 處理令牌過期/無效：

    • 若后端返回 401（令牌過期）或 403（令牌無效），前端需清除本地存儲的令牌，跳轉至登錄頁，并提示“登錄已過期，請重新登錄”；
    • 進階方案：可使用“雙令牌機制”（Access Token + Refresh Token），Access Token 過期時，用 Refresh Token 自動請求新的 Access Token，避免頻繁讓用戶重新登錄。
2.2 后端做什么？

此階段后端無主動操作，但需為后續“令牌驗證”做準備：

  • 確保密鑰和簽名算法的一致性（生成令牌和驗證令牌必須用同一套密鑰和算法）；
  • 若用“雙令牌機制”，需存儲 Refresh Token 的狀態（如是否已過期、是否已注銷），通常存在 Redis 中（便于快速查詢和失效）。

階段 3：接口訪問驗證階段（后端驗證令牌，確認用戶身份）

當前端攜帶 JWT 訪問需要身份驗證的接口時，后端需通過一系列校驗確認令牌合法性，進而允許/拒絕接口訪問。

3.1 前端做什么？

核心動作：發送攜帶令牌的請求 → 處理后端驗證結果

  • 無需額外操作，只需通過請求攔截器自動攜帶令牌（如階段 2 所述）；
  • 接收后端響應：若驗證通過，正常處理接口返回的數據（如渲染用戶信息、訂單列表）；若驗證失敗（401/403），執行“令牌過期處理”（如跳轉登錄頁）。
3.2 后端做什么？

核心動作：提取令牌 → 驗證令牌合法性 → 解析用戶信息 → 權限控制

  1. 提取請求中的令牌：

    • 從請求頭的 Authorization 字段中提取令牌（需先去除 Bearer 前綴）；
    • 若未提取到令牌，直接返回 401 錯誤，提示“請先登錄”。

  2. 驗證令牌合法性（核心步驟）：
    后端需通過 3 重校驗確保令牌有效，缺一不可：

    • 校驗簽名（防篡改）：
      用生成令牌時的密鑰和算法，對令牌的 Header + . + Payload 重新計算簽名，與令牌的 Signature 部分對比；若不一致，說明令牌被篡改，返回 403（Forbidden）錯誤。
    • 校驗過期時間（防永久有效）：
      解碼令牌的 Payload，獲取 exp（過期時間，時間戳格式），與當前服務器時間對比；若 exp < 當前時間，說明令牌已過期，返回 401 錯誤。
    • 校驗令牌有效性（防注銷/黑名單）：
      若項目中存在“主動注銷”功能（如用戶點擊“退出登錄”），后端需將已注銷的令牌加入“黑名單”（通常存在 Redis 中，過期時間與令牌 exp 一致）；校驗時需查詢黑名單，若令牌在黑名單中，返回 401 錯誤。

  3. 解析用戶信息并綁定上下文：

    • 若令牌驗證通過，解碼 Payload 中的 userID、role 等信息；
    • 將用戶信息綁定到當前請求的“上下文”中（如 Java 的 ThreadLocal、Node.js 的 req.user），方便后續接口邏輯直接使用（如查詢“當前用戶的訂單”時，直接從上下文獲取 userID，無需再傳參數）。

  4. 權限控制（可選，基于角色/權限）：

    • 若接口需要特定權限（如“刪除訂單”僅允許管理員操作），從請求上下文提取用戶 role，與接口要求的權限對比；
    • 若權限不滿足，返回 403 錯誤，提示“無操作權限”；若滿足，允許接口繼續執行業務邏輯（如查詢數據庫、返回數據）。

三、核心區別：JWT 與傳統 Session 認證的兩端分工差異

理解 JWT 流程后，可通過對比傳統 Session 認證，更清晰看到 JWT 的“無狀態”優勢：

對比維度JWT 認證傳統 Session 認證
后端存儲無狀態（不存儲令牌，僅存密鑰）需存儲 Session ID（如 Redis/數據庫）
前端存儲存儲 JWT 令牌（localStorage/Cookie）存儲 Session ID（通常在 Cookie 中）
跨服務/跨域支持（令牌自帶身份信息，無需共享 Session）不支持（需共享 Session 存儲，跨域 Cookie 受限）
后端驗證驗證令牌簽名和過期時間（本地計算，速度快）查 Session 存儲確認 ID 有效性（IO 操作，速度慢）

四、安全注意事項（前端 + 后端）

  1. 前端安全：

    • 不存儲敏感信息到 Payload（如密碼、身份證號）；
    • 優先用 Cookie 存儲令牌并開啟 HttpOnly、Secure、SameSite；
    • 避免在 URL 中攜帶令牌（會被日志記錄，泄露風險高）。

  2. 后端安全：

    • 密鑰必須安全存儲（配置中心/環境變量），定期輪換；
    • 令牌過期時間不宜過長（如 1-2 小時），避免長期泄露風險；
    • 開啟 HTTPS 傳輸（防止令牌被中間人攔截竊取）；
    • 實現“令牌黑名單”機制，處理主動注銷場景。

總結：JWT 登錄流程的核心是“后端生成可信令牌，前端攜帶令牌證明身份，后端驗證令牌合法性”。前端的核心職責是“存儲和攜帶令牌”，后端的核心職責是“驗證令牌和控制權限”，二者通過 JWT 令牌實現無狀態的身份認證，解決了傳統 Session 認證的跨域、跨服務痛點。

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/diannao/100337.shtml
繁體地址，請注明出處：http://hk.pswp.cn/diannao/100337.shtml
英文地址，請注明出處：http://en.pswp.cn/diannao/100337.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

MongoDB 在線安裝-一鍵安裝腳本（CentOS 7.9）

MongoDB 在線安裝-一鍵安裝腳本（CentOS 7.9）

1. 腳本概述本腳本用于在 CentOS 7.9 系統上在線安裝 MongoDB&#xff0c;自動處理端口占用和重復安裝問題&#xff0c;并創建管理員用戶 test8&#xff0c;密碼 test123。2. 功能停止并關閉防火墻檢查 27017 端口占用并結束進程如果已安裝 MongoDB&#xff0c;卸載重裝配置 Mo…
閱讀更多...
樹形數據結構之樹狀基礎-算法賽

樹形數據結構之樹狀基礎-算法賽

今天給分享的是一道算法決賽的題目&#xff0c;這道題目的綜合要求比較高&#xff0c;希望大家可以好好理解&#xff0c;同時這道題用到的是樹狀樹形結構的有關知識。可以用這幾天學的相關內容結合起來。問題描述給定兩個長度為 N的排列 A 和 B。若一對二元組下標 (i,j) 滿足以…
閱讀更多...
Jenkins 構建清理策略：自帶功能 vs Discard Old Build 插件，全場景實操指南

Jenkins 構建清理策略：自帶功能 vs Discard Old Build 插件，全場景實操指南

前言&#xff1a;在 Jenkins 持續集成過程中&#xff0c;構建記錄、工作空間、產物包會不斷積累&#xff0c;既占用磁盤空間&#xff0c;也會讓構建歷史變得臃腫。Jenkins 自帶的“丟棄舊的構建”功能和 Discard Old Build 插件&#xff0c;是兩種常見的構建清理方案。本文將詳…
閱讀更多...
Leetcode | Hot100

Leetcode | Hot100

文章目錄兩數之和字母異位詞分組最長連續序列移動零盛水最多的容器三數之和接雨水無重復字符的最長子串找到字符串中所有字母異位詞和為 K 的子數組滑動窗口最大值最小覆蓋子串最大子數組和合并區間輪轉數組除自身以外數組的乘積缺失的第一個正數矩陣置零螺旋矩陣旋轉圖像搜索二…
閱讀更多...
【論文閱讀】Uncertainty Modeling for Out-of-Distribution Generalization (ICLR 2022)

【論文閱讀】Uncertainty Modeling for Out-of-Distribution Generalization (ICLR 2022)

論文題目&#xff1a;Uncertainty Modeling for Out-of-Distribution Generalization 論文來源&#xff1a;ICLR 2022 論文作者&#xff1a; 論文鏈接&#xff1a;https://arxiv.org/pdf/2202.03958 論文源碼&#xff1a;https://github.com/lixiaotong97/DSU ? 一、摘要…
閱讀更多...
分布式系統單點登錄(SSO)狀態管理深度解析：從Cookie+Session到JWT的演進之路

分布式系統單點登錄(SSO)狀態管理深度解析：從Cookie+Session到JWT的演進之路

分布式系統單點登錄(SSO)狀態管理深度解析&#xff1a;從CookieSession到JWT的演進之路作者&#xff1a;默語佬 | CSDN博主 在分布式微服務架構盛行的今天&#xff0c;單點登錄已成為企業級應用的標準配置。本文將深入探討SSO狀態管理的技術演進&#xff0c;從傳統的CookieSess…
閱讀更多...
從 WPF 到 Avalonia 的遷移系列實戰篇7：EventTrigger 的遷移

從 WPF 到 Avalonia 的遷移系列實戰篇7：EventTrigger 的遷移

從 WPF 到 Avalonia 的遷移系列實戰篇7&#xff1a;EventTrigger 的遷移 在 WPF 中&#xff0c;EventTrigger 是非常常用的功能&#xff0c;它可以讓我們直接在 XAML 中綁定事件與動畫或動作&#xff0c;實現 UI 的交互效果。例如按鈕點擊時旋轉、鼠標懸停時變色等。 然而&…
閱讀更多...
深圳比斯特|電池組PACK自動化生產線廠家概述

深圳比斯特|電池組PACK自動化生產線廠家概述

電池組PACK自動化生產線是指用于生產電池模組的一套自動化系統。這類生產線主要用于生產各類電池組&#xff0c;如鋰離子電池組&#xff0c;應用于電動汽車、儲能系統等領域。自動化生產線通過機械設備和計算機控制系統&#xff0c;實現電池組生產過程的自動化和高效率。整條生…
閱讀更多...
基于librdkafa C++客戶端生產者發送數據失敗問題處理#2

基于librdkafa C++客戶端生產者發送數據失敗問題處理#2

https://blog.csdn.net/qq_42896627/article/details/149025452?fromshareblogdetail&sharetypeblogdetail&sharerId149025452&sharereferPC&sharesourceqq_42896627&sharefromfrom_link 上次我們介紹了認證失敗的問題。這次介紹另一個問題生產者發送失敗…
閱讀更多...
pg卡死處理

pg卡死處理

[postgresapm ~]$ ps -ef|grep postgres:|grep -v grep|awk {print $2}|xargs kill -9 鎖&#xff1a; 1 查找鎖表的pid select pid from pg_locks l join pg_class t on l.relation t.oid where t.relkind r and t.relname lockedtable; 2 查找鎖表的語句 select pid, …
閱讀更多...
Spring Boot 與 Elasticsearch 集成踩坑指南：索引映射、批量寫入與查詢性能

Spring Boot 與 Elasticsearch 集成踩坑指南：索引映射、批量寫入與查詢性能

前言Elasticsearch 作為分布式搜索和分析引擎&#xff0c;憑借其高性能、可擴展性和豐富的查詢能力&#xff0c;被廣泛應用于日志分析、全文檢索、電商搜索推薦等場景。 在 Spring Boot 項目中集成 Elasticsearch 已成為很多開發者的日常需求&#xff0c;但真正落地時往往會踩到…
閱讀更多...
windows 10打開虛擬機平臺時，出現錯誤“找不到引用的匯編”解決辦法

windows 10打開虛擬機平臺時，出現錯誤“找不到引用的匯編”解決辦法

通過dism.exe開啟虛擬機平臺時&#xff0c;出現了以下錯誤&#xff1a;找不到引用的匯編&#xff0c;如下圖所示 通過以下命令進行修復均無效&#xff1a; dism /online /cleanup-image /scanhealth sfc /scannow 最后通過加載windows系統的安裝光盤iso, 雙擊setup.exe以【保…
閱讀更多...
設計模式(C++)詳解——建造者模式（1）

設計模式(C++)詳解——建造者模式（1）

<摘要> 建造者模式是一種創建型設計模式&#xff0c;通過將復雜對象的構建過程分解為多個步驟&#xff0c;使相同的構建過程能夠創建不同的表示形式。本文從背景起源、核心概念、設計意圖等角度深入解析該模式&#xff0c;結合電腦組裝、文檔生成等實際案例展示其實現方式…
閱讀更多...
移動端觸摸事件與鼠標事件的觸發機制詳解

移動端觸摸事件與鼠標事件的觸發機制詳解

移動端觸摸事件與鼠標事件的觸發機制詳解 在移動端開發中&#xff0c;我們經常會遇到一個現象&#xff1a;一次簡單的觸摸操作&#xff0c;不僅會觸發touch系列事件&#xff0c;還會觸發一系列mouse事件&#xff0c;最終甚至會觸發click事件。這其實是瀏覽器為了兼容傳統桌面端…
閱讀更多...
如何科學評估CMS系統性能優化效果？

如何科學評估CMS系統性能優化效果？

為什么要評估性能優化效果&#xff1f; 在投入時間精力優化CMS系統后&#xff0c;很多開發者只憑"感覺"判斷網站變快了&#xff0c;但這種主觀判斷往往不可靠。科學評估性能優化效果可以幫助我們&#xff1a; 量化優化成果&#xff1a;用數據證明優化的價值發現潛在問…
閱讀更多...
中控平臺數據監控大屏

中控平臺數據監控大屏

中控平臺數據監控大屏前言&#xff1a;什么是數據大屏&#xff1f; 數據大屏就像是一個"數字儀表盤"&#xff0c;把復雜的數據用圖表、動畫等方式直觀展示出來。想象一下汽車的儀表盤&#xff0c;能讓你一眼看到速度、油量、轉速等信息——數據大屏也是這個原理&…
閱讀更多...
【Vue2手錄13】路由Vue Router

【Vue2手錄13】路由Vue Router

一、Vue Router 基礎概念與核心原理 1.1 路由本質與核心要素 本質定義&#xff1a;路由是URL路徑與頁面組件的對應關系&#xff0c;通過路徑變化控制視圖切換&#xff0c;實現單頁應用&#xff08;SPA&#xff09;的無刷新頁面切換。核心三要素&#xff1a; router-link&#x…
閱讀更多...
【Git】零基礎入門：配置與初始操作實戰指南

【Git】零基礎入門：配置與初始操作實戰指南

目錄 1.前言 插播一條消息~ 2.正文 2.1概念 2.2安裝與配置 2.3基礎操作 2.3.1創建本地倉庫 2.3.2配置Git 2.3.3認識工作區&#xff0c;暫存區&#xff0c;版本庫 2.3.4版本回退 2.3.5撤銷修改 2.3.6刪除文件 3.小結 1.前言 在 Java 開發場景中&#xff0c;團隊協…
閱讀更多...
CAD多面體密堆積_圓柱體試件3D插件

CAD多面體密堆積_圓柱體試件3D插件

插件介紹 CAD多面體密堆積_圓柱體試件3D插件可在AutoCAD內基于重力堆積算法在圓柱體容器內進行多面體的密堆積三維建模。插件采取堆積可視化交互界面&#xff0c;可觀察多面體顆粒的堆積動態&#xff0c;并可采用鼠標進行多面體位置的局部微調。插件可設置重力堆積模擬時長參數…
閱讀更多...
機器學習-模型調參、超參數優化

機器學習-模型調參、超參數優化

模型調參 手工超參數微調 以一個好的baseline開始&#xff0c;即&#xff1a;在一些高質量的工具包中的默認設置&#xff0c;論文中的值調一個值&#xff0c;重新訓練這個模型來觀察變化重復很多次獲得對以下的insight&#xff1a; 1、哪個超參數重要 2、模型對超參數的敏感度是…
閱讀更多...
最新文章

Copyright @ 2022~2023