一文搞懂前後端常見登錄態方案

来源:https://www.cnblogs.com/88223100/archive/2022/12/20/One-article-to-understand-the-common-login-schemes-of-the-front-and-rear-end.html
-Advertisement-
Play Games

正文開始之前,我們先要瞭解一個概念,就是什麼是 登錄態。 主流Web應用比如瀏覽器是基於http協議的,而http協議是 無狀態 的。什麼是 無狀態?就是伺服器不知道是誰發送了這個http請求,無法識別區分用戶身份。 所以登錄態就是服務端用來區分用戶身份,同時對用戶進行記錄的技術方案。 ...


 

 

正文開始之前,我們先要瞭解一個概念,就是什麼是 登錄態

主流Web應用比如瀏覽器是基於http協議的,而http協議是 無狀態 的。什麼是 無狀態?就是伺服器不知道是誰發送了這個http請求,無法識別區分用戶身份。

所以登錄態就是服務端用來區分用戶身份,同時對用戶進行記錄的技術方案。

那怎麼實現用戶的登錄態呢?常見的實現流程如下:

  1. 客戶端用戶輸入登錄憑據(如賬戶和密碼),發送登錄請求。
  2. 服務端校驗用戶是否合法(如認證和鑒權),合法後返回登錄態,不合法返回第1步。
  3. 合法後攜帶登錄態訪問用戶數據。

流程有了,如何實現呢?

常見的方案有HTTP基本認證、Cookie和Session認證、Token認證、單點登錄認證等,下麵一一介紹。

1. HTTP基本認證

HTTP基本認證是HTTP協議本身提供了一種服務端對客戶端進行用戶身份驗證的方法。 流程如下:

sequenceDiagram
autonumber
客戶端->>服務端:Get / HTTP/1.1 Host:www.qq.com
服務端->>客戶端:HTTP/1.1 401 Unauthorised WWW-Authenticate: Basic realm="qq.com"
客戶端->>客戶端:彈出登錄視窗
客戶端->>服務端:Get / HTTP/1.1 Host:www.qq.com Authorization: Basic xxxxxx
服務端->>客戶端:驗證成功,返回用戶數據
  1. 客戶端向服務端請求需要登錄態的數據
  2. 服務端向客戶端返回401狀態碼,要求客戶端驗證
  3. 客戶端根據返回的 WWW-Authenticate: Basic realm="qq.com",彈出用戶名和密碼輸入框要求用戶進行驗證。
  4. 用戶輸入用戶名和密碼後,客戶端將用戶名及密碼以 Base64 格式發送給服務端。
  5. 服務端驗證通過後返回用戶數據。

這是一種比較簡單的驗證用戶身份的方式,甚至不需要寫代碼,只要後端伺服器配置一下即可。

優點:相容性好,主流瀏覽器都支持

缺點:

  • 不安全,賬號密碼是Base64編碼,很容易解碼。
  • 無法主動註銷,除非關閉標簽或瀏覽器。

2. Cookie和Session認證

先瞭解兩個概念,Cookie和Session是什麼呢? 上面說到HTTP是一種無狀態協議,而Cookie和Session可以彌補 HTTP 的無狀態特性。

2.1 什麼是Cookie

Cookie是客戶端請求服務端時,由服務端創建並由客戶端存儲和管理的小文本文件。具體流程如下:

  • 客戶端首次發起請求。
  • 服務端通過HTTP響應頭裡Set-Cookie欄位返回Cookie信息。
  • 客戶端再發起請求時會通過HTTP請求頭裡Cookie欄位攜帶Cookie信息。

2.2 什麼是Session

Session是客戶端請求服務端時服務端會為這次請求創建一個數據結構,這個結構可以通過記憶體、文件、資料庫等方式保存。具體流程如下:

  • 客戶端首次發起請求。
  • 服務端收到請求並自動為該客戶端創建特定的Session並返回SessionID,用來標識該客戶端。
  • 客戶端通過服務端響應獲取SessionID,併在後續請求攜帶SessionID。
  • 服務端根據收到的SessionID,在服務端找對應的Session,進而獲取到客戶端信息。

2.3 Cookie和Session認證流程

  1. 客戶端向服務端發送認證信息(例如賬號密碼)
  2. 服務端根據客戶端提供的認證信息執行驗證邏輯,如果驗證成功則生成Session並保存,同時通過響應頭Set-Cookie欄位返回對應的SessionID
  3. 客戶端再次請求併在Cookie里攜帶SessionID。
  4. 服務端根據SessionID查找對應的Session,並根據業務邏輯返回相應的數據。

2.4 Cookie和Session認證優點

  • Cookie由客戶端管理,支持設定有效期、安全加密、防篡改、請求路徑等屬性。
  • Session由服務端管理,支持有效期,可以存儲各類數據。

2.4 Cookie和Session認證缺點

  • Cookie只能存儲字元串,有大小和數量限制,對移動APP端支持不好,同時有跨域限制(主域不同)。
  • Session存儲在服務端,對服務端有性能開銷,客戶端量太大會影響性能。如果集中存儲(如存儲在Redis),會帶來額外的部署維護成本。

3. Token認證

Token又叫令牌,是服務端生成用來驗證客戶端身份的憑證,客戶端每次請求都攜帶Token。 Token一般由以下數據組成:

uid(用戶唯一的身份標識)
time(當前時間的時間戳)
sign(簽名,由token的前幾位+鹽用哈希演算法壓縮成一定長的十六進位字元串)

3.1 Token認證流程

  1. 客戶端向服務端發送認證信息(例如賬號密碼)
  2. 服務端根據客戶端提供的認證信息執行驗證邏輯(如查詢資料庫),如果驗證成功則生成Token並返回。
  3. 客戶端存儲(可以存在Cookie、LocalStorage或本地緩存里)收到的Token,再次請求時攜帶Token(可以通過HTTP請求頭Authorization欄位)。
  4. 服務端校驗Token(如查詢資料庫),並根據業務邏輯返回相應的數據。

3.2 Token認證優點

  • 客戶端可以用Cookie、LocalStorage等存儲,服務端不需要存儲。
  • 安全性高(有簽名校驗)。
  • 支持移動APP端。
  • 支持跨域。

3.3 Token認證缺點

  • 占用額外傳輸寬頻,因為Token比較大,可能會消耗一定的流量。
  • 每次簽名校驗會消耗服務端性能。
  • 有效期短(避免被盜用)。

3.4 Refresh Token

3.3里說到為了避免被盜用Token一般有效期比較短。但是有效期太短會造成客戶端不斷重新登錄,體驗太差。有沒有什麼辦法可以解決這個問題呢?

那就是再來一個Token,一個專門生成Token的Token,稱為 Refresh Token

流程如下:

  1. 客戶端向服務端發送認證信息(例如賬號密碼)
  2. 服務端根據客戶端提供的認證信息執行驗證邏輯(如查詢資料庫),如果驗證成功則生成Token和Refresh Token並返回。
  3. 客戶端存儲(可以存在Cookie、LocalStorage或本地緩存里)收到的Token和Refresh Token,再次請求時攜帶Token(可以通過HTTP請求頭Authorization欄位)。
  4. 服務端校驗Token(如查詢資料庫),並根據業務邏輯返回相應的數據。
  5. 服務端發現Token過期了,拒絕了請求。
  6. 客戶端重新請求並攜帶Refresh Token。
  7. 服務端校驗Refresh Token並返回新Token和新Refresh Token。
  8. 客戶端再次請求並攜帶新Token。

3.5 JWT

3.3、3.4里服務端校驗客戶端發過來的Token是否有效時,可能會查詢資料庫來驗證。如果每次請求都要查詢資料庫,可能會帶來額外性能消耗。

那這個有沒有辦法優化呢?

答案是有的,那就是JWT(JSON Web Token)。JWT 是 Auth0 提出的通過 對JSON進行加密簽名 來實現授權驗證的方案。

JWT也是一種Token,由三部分組成: Header頭部 、 Payload負載 和 Signature簽名。它是一個很長的字元串,中間用點( . )分隔成三個部分,列如 :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header頭部:
{
   "alg": "Hash演算法(HMAC、SHA256或RSA)",
   "typ": "Token的類型(JWT)"
 }

Payload負載:

{
   "iss": "簽發人(issuer)",
   "exp": "過期時間(expiration time)",
   "sub": "主題(subject)",
   "aud": "受眾(audience)",
   "nbf": "生效時間(not before)",
   "iat": "簽發時間(issued at)",
   "jti": "編號(JWT ID)",
   "uid": "自定義欄位(可以存儲用戶ID等)",
 }

Signature 簽名:

HMACSHA256(
   base64UrlEncode(header) + "." + base64UrlEncode(payload),
   secret //設置的密鑰
)

 

JWT的流程和Token的基本一樣,因為已經攜帶了客戶端信息(如用戶ID等),所以服務端校驗Token時不需要查詢資料庫了。

4. 單點登錄認證

上面說的都是同一個功能變數名稱(或同一主域)下,通過Cookie或Token攜帶憑證實現登錄態管理。但是如果有很多功能變數名稱,如何實現用戶在一個功能變數名稱下登錄後,訪問另一個功能變數名稱也能自動登錄呢?

這就是單點登錄問題(Single Sign On

要實現SSO,需要有一個CAS(Central Authentication Service)中央授權服務(假設功能變數名稱為cas.com)來提供統一的登錄功能。

假如現在有功能變數名稱要實現互相自動登錄。流程如下:

先訪問

再訪問

先訪問

  1. 客戶端訪問
  2. 發現沒有登錄(域下沒有Session或Session失效),302跳轉到並攜帶的回調地址(登錄成功跳轉回來的頁面鏈接)。
  3. 發現沒有登錄(域下沒有Session或Session失效),302跳轉到登錄頁面並攜帶的回調地址。
  4. 客戶端攜帶回調地址訪問
  5. 客戶端向發送認證信息(例如賬號密碼)。
  6. 登錄成功並生成域下的Session,同時生成一個Token,根據回調地址攜帶此Token重定向到
  7. 客戶端攜帶Token訪問
  8. 訪問驗證Token的有效性,驗證成功並生成域下的Session,完成登錄。

再訪問

  1. 客戶端訪問
  2. 校驗失敗,需要登錄(域下沒有Session或Session失效),302重定向到,並攜帶回調地址。
  3. 客戶端攜帶回調地址訪問
  4. 根據下的Session(訪問時生成的)發現用戶已登錄,生成Token後302重定向到
  5. 訪問驗證Token的有效性,驗證成功並生成域下的Session,完成登錄。

總結:

  • HTTP基本認證:一般用於對安全要求不高或內部系統用戶量極少的場景,實際應用不多。
  • Cookie和Session認證:一般應用於瀏覽器環境。
  • Token認證:除了瀏覽器環境外,還可以應用於移動端APP、小程式、PC端軟體等非瀏覽器環境。
  • 單點登錄認證:應用於大型站群系統或企業內不同業務系統間互通。

以上總結4種了常見的登錄方案,還有OAuth2.0、掃碼登錄等方式,後續還會繼續更新,敬請期待。。。

 

作者:yanweiyao

本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/One-article-to-understand-the-common-login-schemes-of-the-front-and-rear-end.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 摘要:openGemini的設計和優化都是根據時序數據特點而來,在面對海量運維監控數據處理需求時,openGemini顯然更加有針對性。 IT運維誕生於最早的信息化時代。在信息化時代,企業的信息化系統,主要為了滿足企業內部管理的需求。通常是集中、可控和固化的煙囪式架構。傳統IT運維,以人力運維為主, ...
  • 說說幾種薅免費伺服器羊毛的方法吧 經過我多年的薅羊毛經驗,總結得知,編程只需要: Terminal + VPS主機 + 網路 為了達到這些目的,肯定需要Vim搭建IDE,安裝環境等等操作 當時記得使用的是ChromeOS的筆記本,所有的應用都是在Chrome瀏覽器當中的,續航時間長,又輕薄屬實快得飛 ...
  • 主要闡述InnoDB存儲引擎(MySQL5以後的預設引擎)。 資料庫中最基本的組成結構是數據表,視覺上的表和其對應的磁碟結構如下: 此圖參考了廈門大學課堂:MySQL原理 。但是視頻中一些更多細節沒有涉及,比如Leaf node segment和Non-leaf node segment其實就是葉子 ...
  • 在先前舉辦的華為開發者大會2022(HDC)上,華為通過3D數字溪村展示了自有3D引擎“HMS Core 3D Engine”(以下簡稱3D Engine)的強大能力。作為一款高性能、高畫質、高擴展性的3D引擎,3D Engine不僅能通過實時光追、水體渲染、體積雲霧、多維GPU粒子系統等技術還原真 ...
  • 好家伙,本篇為《JS高級程式設計》第八章“對象、類與面向對象編程”學習筆記 1.關於對象 ECMA-262將對象定義為一組屬性的無序集合。嚴格來說,這意味著對象就是一組沒有特定順序的值。 對象的每個屬性或方法都由一個名稱來標識,這個名稱映射到一個值。正因為如此(以及其他還未討論的原因),可以把 EC ...
  • 這裡給大家分享我在網上總結出來的一些知識,希望對大家有所幫助 不想看繁瑣步驟的,可以直接去github下載項目,如果可以順便來個star哈哈 本項目使用vue-cli創建,但不影響使用,主要繪製都已封裝成類 1、使用geoJson繪製3d地圖 1.1 創建場景相關 // 創建webGL渲染器 thi ...
  • “像白天不懂夜的黑,像永恆燃燒的太陽,不懂那月亮的盈缺。” —— 黃桂蘭 0x00 大綱 0x01 前言 夜間模式(Dark Mode),也被稱為黑暗模式或深色模式,是一種高對比度,或者反色模式的顯示模式,這種模式現在越來越流行,因為和傳統的白底黑字相比,這種黑底白字的模式通常被認為可以緩解眼疲勞, ...
  • 前言 今年又是一個非常寒冷的冬天,很多公司都開始人員精簡。市場從來不缺前端,但對高級前端的需求還是特別強烈的。一些大廠的面試官為了區分候選人對前端領域能力的深度,經常會在面試過程中考察一些前端框架的源碼性知識點。Vuejs 作為世界頂尖的框架之一,幾乎在所有的面試場景中或多或少都會被提及。 筆者之前 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...