簡(jiǎn)介這份資源是面向高校計(jì)算機(jī)相關(guān)專業(yè)畢業(yè)設(shè)計(jì)的完整項(xiàng)目包主題為基于Python與Django的Web服務(wù)統(tǒng)一身份認(rèn)證協(xié)議設(shè)計(jì)適合正在準(zhǔn)備畢設(shè)或需要學(xué)習(xí)單點(diǎn)登錄與身份認(rèn)證實(shí)現(xiàn)的學(xué)生及開發(fā)者參考。項(xiàng)目采用B/S架構(gòu)后端基于Django框架配合MySQL數(shù)據(jù)庫完成數(shù)據(jù)持久化核心功能涵蓋用戶信息管理查看、修改、刪除以及單點(diǎn)登錄機(jī)制通過一次服務(wù)器認(rèn)證即可訪問相互信任的站點(diǎn)并按權(quán)限分配策略實(shí)現(xiàn)自動(dòng)登錄與差異化訪問。壓縮包共603個(gè)文件約8.34MB包含105個(gè)py源碼文件、13個(gè)html頁面、52個(gè)js腳本、21個(gè)css樣式以及大量png、gif等界面素材另附數(shù)據(jù)庫文件、說明文檔與演示視頻便于理解整體結(jié)構(gòu)與運(yùn)行流程。目前已有904人學(xué)習(xí)下載可作為畢設(shè)選題落地的參考方案幫助讀者快速掌握統(tǒng)一身份認(rèn)證系統(tǒng)的設(shè)計(jì)思路與關(guān)鍵實(shí)現(xiàn)細(xì)節(jié)。1. 從一份畢業(yè)設(shè)計(jì)壓縮包說起Web 服務(wù)統(tǒng)一身份認(rèn)證到底在解決什么你拿到手的這個(gè)(基于python的畢業(yè)設(shè)計(jì))web服務(wù)統(tǒng)一身份認(rèn)證協(xié)議設(shè)計(jì)(源碼說明演示視頻).zip名字很長但核心就一件事讓多個(gè) Web 服務(wù)共用一套登錄態(tài)而不是每個(gè)子系統(tǒng)各存一份用戶名密碼。做過課程設(shè)計(jì)的人都懂教務(wù)系統(tǒng)、圖書館、選課平臺(tái)各登一次密碼還要求不一樣這就是典型的身份孤島。統(tǒng)一身份認(rèn)證協(xié)議要做的是把「你是誰」這件事從各個(gè)業(yè)務(wù)系統(tǒng)里抽出來交給一個(gè)獨(dú)立的認(rèn)證中心業(yè)務(wù)系統(tǒng)只負(fù)責(zé)拿著令牌去問「這個(gè)人合法嗎」。這個(gè)方向適合兩類人一類是正在做計(jì)算機(jī)畢業(yè)設(shè)計(jì)、需要一套能跑起來、能講清楚原理、還能錄演示視頻的完整方案另一類是想理解 SSO單點(diǎn)登錄和令牌校驗(yàn)機(jī)制、但不想一上來就啃 CAS 或 OAuth2 全量規(guī)范的開發(fā)者。標(biāo)題里的「協(xié)議設(shè)計(jì)」不是讓你去發(fā)明新協(xié)議而是讓你基于現(xiàn)有成熟協(xié)議常見做法是 OAuth2 的授權(quán)碼模式或簡(jiǎn)化版 CAS做一套可落地的實(shí)現(xiàn)。Python 在這里的角色是認(rèn)證中心服務(wù)端和客戶端 SDK 的實(shí)現(xiàn)語言選它是因?yàn)樯鷳B(tài)里 Flask、requests、PyJWT 這些庫足夠把協(xié)議流程串起來代碼量可控答辯時(shí)也講得清。我見過太多畢業(yè)設(shè)計(jì)卡在「能演示但說不清協(xié)議流程」這一步。演示視頻里點(diǎn)一下登錄就跳轉(zhuǎn)了老師問一句「令牌怎么防篡改」就答不上來。所以這篇筆記不按論文目錄走而是按一個(gè)真實(shí)可復(fù)現(xiàn)的落地路徑來拆先講清協(xié)議選型和令牌設(shè)計(jì)再動(dòng)手把認(rèn)證中心、業(yè)務(wù)客戶端、令牌校驗(yàn)三塊跑通最后把踩過的坑和進(jìn)階驗(yàn)證方法攤開。你照著做至少能拿到一個(gè)能講、能改、能擴(kuò)展的工程骨架。2. 協(xié)議選型與令牌設(shè)計(jì)為什么不用 Session 共享而用令牌2.1 三種常見方案的取舍Session 共享、CAS、OAuth2 簡(jiǎn)化模式做 Web 服務(wù)統(tǒng)一身份認(rèn)證繞不開的第一個(gè)決策就是「登錄態(tài)存在哪、怎么傳」。最省事的做法是 Session 共享把多個(gè)服務(wù)的 Session 存到同一個(gè) Redis 里瀏覽器帶著同一個(gè) Cookie 就能識(shí)別。這個(gè)方案在單機(jī)或內(nèi)網(wǎng)小規(guī)模場(chǎng)景下確實(shí)能用但它有兩個(gè)硬傷一是跨域場(chǎng)景下 Cookie 的 SameSite 和 Domain 限制會(huì)讓你反復(fù)翻車二是業(yè)務(wù)系統(tǒng)直接依賴 Session 存儲(chǔ)認(rèn)證中心和業(yè)務(wù)系統(tǒng)耦合太深擴(kuò)展性差。畢業(yè)設(shè)計(jì)如果只做 Session 共享答辯時(shí)很難體現(xiàn)「協(xié)議設(shè)計(jì)」四個(gè)字。CASCentral Authentication Service是經(jīng)典的單點(diǎn)登錄協(xié)議流程清晰用戶訪問業(yè)務(wù)系統(tǒng)業(yè)務(wù)系統(tǒng)發(fā)現(xiàn)沒登錄就重定向到 CAS 服務(wù)端服務(wù)端認(rèn)證后帶 ticket 跳回業(yè)務(wù)系統(tǒng)拿 ticket 去服務(wù)端校驗(yàn)。它的優(yōu)點(diǎn)是協(xié)議簡(jiǎn)單、票據(jù)一次性、安全性好缺點(diǎn)是移動(dòng)端和前后端分離場(chǎng)景下重定向流程比較別扭而且 CAS 的 ticket 校驗(yàn)是服務(wù)端到服務(wù)端的同步調(diào)用高并發(fā)時(shí)認(rèn)證中心壓力集中。OAuth2 的授權(quán)碼模式是當(dāng)前更通用的選擇雖然它本意是授權(quán)而非認(rèn)證但加上openid或自定義用戶信息接口后完全可以承擔(dān)統(tǒng)一身份認(rèn)證的職責(zé)。它的核心是業(yè)務(wù)系統(tǒng)引導(dǎo)用戶到認(rèn)證中心用戶認(rèn)證后認(rèn)證中心返回授權(quán)碼業(yè)務(wù)系統(tǒng)用授權(quán)碼換令牌再用令牌獲取用戶信息。這個(gè)流程前后端分離友好令牌可以自包含JWT業(yè)務(wù)系統(tǒng)本地就能校驗(yàn)不必每次都回認(rèn)證中心。對(duì)于畢業(yè)設(shè)計(jì)我一般建議選 OAuth2 授權(quán)碼模式的簡(jiǎn)化版保留授權(quán)碼換令牌的核心流程令牌用 JWT 自包含業(yè)務(wù)系統(tǒng)本地校驗(yàn)簽名和過期時(shí)間。這樣既體現(xiàn)了協(xié)議設(shè)計(jì)又不會(huì)因?yàn)橐胪暾?OAuth2 的刷新令牌、作用域、同意頁而把代碼量撐到失控。2.2 JWT 令牌的結(jié)構(gòu)與簽名參數(shù)怎么定選 JWT 作為令牌載體是因?yàn)樗延脩魳?biāo)識(shí)、過期時(shí)間、簽發(fā)者都編碼進(jìn)令牌本身業(yè)務(wù)系統(tǒng)不需要查庫就能完成校驗(yàn)。一個(gè)典型的 JWT 由三部分組成Header、Payload、Signature用點(diǎn)號(hào)連接。Header 聲明簽名算法Payload 放聲明claimsSignature 是對(duì)前兩部分的簽名。下面是一個(gè)用 Python 生成 JWT 的最小代碼依賴PyJWT庫import jwt import time # 簽名密鑰生產(chǎn)環(huán)境必須從環(huán)境變量讀取不能硬編碼 SECRET_KEY your-256-bit-secret-change-in-production # 簽名算法HS256 是對(duì)稱加密認(rèn)證中心和業(yè)務(wù)系統(tǒng)共享密鑰 ALGORITHM HS256 def create_token(user_id: str, username: str, expire_seconds: int 3600) - str: 生成 JWT 令牌 :param user_id: 用戶唯一標(biāo)識(shí) :param username: 用戶名用于業(yè)務(wù)系統(tǒng)展示 :param expire_seconds: 過期時(shí)間默認(rèn) 1 小時(shí) :return: 編碼后的 JWT 字符串 now int(time.time()) payload { iss: auth-center, # 簽發(fā)者業(yè)務(wù)系統(tǒng)可校驗(yàn) sub: user_id, # 主題通常是用戶 ID name: username, # 自定義聲明用戶展示名 iat: now, # 簽發(fā)時(shí)間 exp: now expire_seconds, # 過期時(shí)間必須設(shè)置 jti: f{user_id}-{now} # 令牌唯一 ID可用于黑名單 } token jwt.encode(payload, SECRET_KEY, algorithmALGORITHM) return token def verify_token(token: str) - dict: 校驗(yàn) JWT 令牌失敗會(huì)拋異常 :param token: 待校驗(yàn)的令牌 :return: 解碼后的 payload try: payload jwt.decode( token, SECRET_KEY, algorithms[ALGORITHM], issuerauth-center, # 校驗(yàn)簽發(fā)者 options{require: [exp, sub, iss]} # 強(qiáng)制要求這些聲明存在 ) return payload except jwt.ExpiredSignatureError: raise ValueError(令牌已過期) except jwt.InvalidTokenError as e: raise ValueError(f令牌無效: {e})這段代碼里幾個(gè)參數(shù)值得展開說。SECRET_KEY的長度和隨機(jī)性直接決定簽名強(qiáng)度HS256 要求密鑰至少 256 位也就是 32 字節(jié)。很多畢業(yè)設(shè)計(jì)里直接寫secret或者123456這在答辯時(shí)是明顯的扣分點(diǎn)因?yàn)楣粽吣玫矫荑€就能偽造任意用戶令牌。exp過期時(shí)間必須設(shè)置不設(shè)過期時(shí)間的令牌一旦泄露就是永久后門。iss簽發(fā)者聲明用于業(yè)務(wù)系統(tǒng)確認(rèn)令牌確實(shí)來自認(rèn)證中心而不是其他服務(wù)簽發(fā)的。jti是令牌唯一 ID如果你要做登出或強(qiáng)制下線就需要維護(hù)一個(gè)黑名單把未過期但已登出的jti記下來校驗(yàn)時(shí)額外查一次。提示HS256 是對(duì)稱算法認(rèn)證中心和所有業(yè)務(wù)系統(tǒng)共享同一個(gè)密鑰。如果業(yè)務(wù)系統(tǒng)數(shù)量多、部署環(huán)境不可控建議換成 RS256 非對(duì)稱算法認(rèn)證中心用私鑰簽名業(yè)務(wù)系統(tǒng)用公鑰驗(yàn)簽私鑰不出認(rèn)證中心。2.3 授權(quán)碼換令牌的完整時(shí)序與接口約定協(xié)議流程要落地必須把接口約定清楚。簡(jiǎn)化版 OAuth2 授權(quán)碼模式涉及四個(gè)角色用戶瀏覽器、業(yè)務(wù)系統(tǒng)客戶端、認(rèn)證中心、用戶信息接口。核心時(shí)序是用戶訪問業(yè)務(wù)系統(tǒng)受保護(hù)頁面業(yè)務(wù)系統(tǒng)發(fā)現(xiàn)無令牌重定向到認(rèn)證中心授權(quán)頁帶上client_id和redirect_uri。用戶在認(rèn)證中心登錄認(rèn)證中心生成一次性授權(quán)碼code重定向回redirect_uri?codexxx。業(yè)務(wù)系統(tǒng)后端拿code調(diào)用認(rèn)證中心令牌接口換取access_token。業(yè)務(wù)系統(tǒng)用access_token調(diào)用用戶信息接口拿到用戶標(biāo)識(shí)建立本地會(huì)話或直接返回給前端。接口約定用表格列清楚避免前后端聯(lián)調(diào)時(shí)扯皮接口方法路徑關(guān)鍵參數(shù)返回授權(quán)頁GET/oauth/authorizeclient_id, redirect_uri, state重定向帶 code令牌接口POST/oauth/tokencode, client_id, client_secretaccess_token, token_type, expires_in用戶信息GET/oauth/userinfoAuthorization: Bearer tokenuser_id, username令牌校驗(yàn)POST/oauth/verifytokenvalid, payloadstate參數(shù)是防 CSRF 的關(guān)鍵業(yè)務(wù)系統(tǒng)生成隨機(jī)字符串存在本地回調(diào)時(shí)比對(duì)不一致就拒絕。client_secret是業(yè)務(wù)系統(tǒng)的憑證必須后端保存絕不能出現(xiàn)在前端代碼里。授權(quán)碼code必須一次性使用用過即失效且有效期建議不超過 5 分鐘。3. 用 Flask 把認(rèn)證中心跑起來路由、授權(quán)碼與令牌簽發(fā)3.1 認(rèn)證中心的最小工程結(jié)構(gòu)與依賴認(rèn)證中心是整個(gè)方案的核心它負(fù)責(zé)用戶登錄、授權(quán)碼生成、令牌簽發(fā)和用戶信息提供。用 Flask 來實(shí)現(xiàn)是因?yàn)樗p量、路由清晰、和 PyJWT 配合簡(jiǎn)單。工程結(jié)構(gòu)不需要復(fù)雜畢業(yè)設(shè)計(jì)階段四個(gè)文件足夠auth-center/ ├── app.py # 主應(yīng)用路由和業(yè)務(wù)邏輯 ├── models.py # 用戶模型和授權(quán)碼存儲(chǔ) ├── config.py # 配置項(xiàng)密鑰、過期時(shí)間 └── requirements.txt # 依賴清單依賴清單里核心是三個(gè)庫Flask提供 Web 框架PyJWT負(fù)責(zé)令牌編解碼flask-cors處理跨域前后端分離時(shí)業(yè)務(wù)系統(tǒng)域名和認(rèn)證中心域名不同。安裝命令pip install Flask PyJWT flask-corsconfig.py里把密鑰、授權(quán)碼有效期、令牌有效期集中管理避免散落在各處import os class Config: # 生產(chǎn)環(huán)境從環(huán)境變量讀取開發(fā)環(huán)境給默認(rèn)值 SECRET_KEY os.environ.get(AUTH_SECRET_KEY, dev-secret-key-32-bytes-long!!!) JWT_ALGORITHM HS256 # 授權(quán)碼有效期單位秒 AUTH_CODE_EXPIRE 300 # 令牌有效期單位秒 TOKEN_EXPIRE 3600 # 允許的業(yè)務(wù)系統(tǒng) client_id 和 secret 映射 CLIENTS { web-app-1: {secret: app1-secret, redirect_uris: [http://localhost:5001/callback]}, web-app-2: {secret: app2-secret, redirect_uris: [http://localhost:5002/callback]}, }CLIENTS字典模擬了業(yè)務(wù)系統(tǒng)注冊(cè)表每個(gè)業(yè)務(wù)系統(tǒng)有獨(dú)立的client_id和client_secret以及允許的回調(diào)地址白名單?；卣{(diào)地址白名單是防開放重定向的關(guān)鍵如果不對(duì)redirect_uri做校驗(yàn)攻擊者可以構(gòu)造惡意回調(diào)地址竊取授權(quán)碼。3.2 授權(quán)碼的生成、存儲(chǔ)與一次性消費(fèi)授權(quán)碼是連接授權(quán)頁和令牌接口的臨時(shí)憑證它的安全性要求是隨機(jī)、短有效期、一次性。用 Python 的secrets模塊生成隨機(jī)碼比random模塊更適合安全場(chǎng)景。import secrets import time from threading import Lock class AuthCodeStore: 授權(quán)碼存儲(chǔ)內(nèi)存實(shí)現(xiàn)生產(chǎn)環(huán)境應(yīng)換成 Redis def __init__(self, expire_seconds300): self._store {} # code - {user_id, client_id, expire_at} self._lock Lock() self._expire expire_seconds def generate(self, user_id: str, client_id: str) - str: 生成授權(quán)碼并存儲(chǔ) code secrets.token_urlsafe(32) # 32 字節(jié)隨機(jī)URL 安全 with self._lock: self._store[code] { user_id: user_id, client_id: client_id, expire_at: time.time() self._expire } return code def consume(self, code: str, client_id: str) - str: 消費(fèi)授權(quán)碼返回 user_id 一次性取出即刪除校驗(yàn) client_id 和過期時(shí)間 with self._lock: record self._store.pop(code, None) if record is None: raise ValueError(授權(quán)碼不存在或已使用) if record[client_id] ! client_id: raise ValueError(授權(quán)碼與客戶端不匹配) if time.time() record[expire_at]: raise ValueError(授權(quán)碼已過期) return record[user_id]secrets.token_urlsafe(32)生成的是 32 字節(jié)隨機(jī)數(shù)的 URL 安全 Base64 編碼長度約 43 個(gè)字符暴力猜測(cè)不可行。consume方法里pop操作保證了一次性無論后續(xù)校驗(yàn)是否通過授權(quán)碼都已經(jīng)被移除攻擊者無法重放。client_id校驗(yàn)防止一個(gè)業(yè)務(wù)系統(tǒng)拿另一個(gè)業(yè)務(wù)系統(tǒng)的授權(quán)碼去換令牌。過期時(shí)間校驗(yàn)放在最后是因?yàn)榧词故跈?quán)碼泄露5 分鐘后也自動(dòng)失效。3.3 令牌接口與用戶信息接口的實(shí)現(xiàn)令牌接口接收code、client_id、client_secret校驗(yàn)通過后簽發(fā) JWT。用戶信息接口從Authorization頭里取令牌校驗(yàn)后返回用戶信息。from flask import Flask, request, jsonify, redirect from config import Config from models import AuthCodeStore, UserStore import jwt import time app Flask(__name__) app.config.from_object(Config) code_store AuthCodeStore(expire_secondsapp.config[AUTH_CODE_EXPIRE]) user_store UserStore() app.route(/oauth/token, methods[POST]) def token(): 授權(quán)碼換令牌接口 data request.get_json() code data.get(code) client_id data.get(client_id) client_secret data.get(client_secret) # 校驗(yàn)客戶端身份 client app.config[CLIENTS].get(client_id) if not client or client[secret] ! client_secret: return jsonify({error: invalid_client}), 401 # 消費(fèi)授權(quán)碼 try: user_id code_store.consume(code, client_id) except ValueError as e: return jsonify({error: str(e)}), 400 # 簽發(fā)令牌 now int(time.time()) payload { iss: auth-center, sub: user_id, iat: now, exp: now app.config[TOKEN_EXPIRE], jti: f{user_id}-{now} } access_token jwt.encode(payload, app.config[SECRET_KEY], algorithmapp.config[JWT_ALGORITHM]) return jsonify({ access_token: access_token, token_type: Bearer, expires_in: app.config[TOKEN_EXPIRE] }) app.route(/oauth/userinfo, methods[GET]) def userinfo(): 用戶信息接口從 Bearer 令牌中解析用戶 auth_header request.headers.get(Authorization, ) if not auth_header.startswith(Bearer ): return jsonify({error: missing_token}), 401 token auth_header[7:] try: payload jwt.decode( token, app.config[SECRET_KEY], algorithms[app.config[JWT_ALGORITHM]], issuerauth-center ) except jwt.ExpiredSignatureError: return jsonify({error: token_expired}), 401 except jwt.InvalidTokenError: return jsonify({error: invalid_token}), 401 user user_store.get(payload[sub]) if not user: return jsonify({error: user_not_found}), 404 return jsonify({user_id: user[id], username: user[username]})令牌接口里客戶端身份校驗(yàn)放在最前面避免無效請(qǐng)求消耗授權(quán)碼。jwt.encode的 payload 里sub是用戶 IDjti用于后續(xù)黑名單。用戶信息接口的Authorization頭格式必須是Bearer token解析時(shí)注意空格。jwt.decode的issuer參數(shù)會(huì)校驗(yàn)iss聲明防止其他服務(wù)簽發(fā)的令牌混入。注意內(nèi)存存儲(chǔ)的授權(quán)碼和用戶數(shù)據(jù)在服務(wù)重啟后會(huì)丟失畢業(yè)設(shè)計(jì)演示時(shí)如果中途重啟服務(wù)需要重新登錄。生產(chǎn)環(huán)境或需要持久化的場(chǎng)景把AuthCodeStore換成 Redis 實(shí)現(xiàn)UserStore換成數(shù)據(jù)庫查詢。4. 業(yè)務(wù)系統(tǒng)接入客戶端 SDK 與令牌本地校驗(yàn)4.1 業(yè)務(wù)系統(tǒng)如何發(fā)起授權(quán)跳轉(zhuǎn)與處理回調(diào)業(yè)務(wù)系統(tǒng)接入統(tǒng)一身份認(rèn)證核心是三件事未登錄時(shí)跳轉(zhuǎn)認(rèn)證中心、處理回調(diào)拿令牌、本地校驗(yàn)令牌。用 Flask 寫一個(gè)業(yè)務(wù)系統(tǒng)的最小實(shí)現(xiàn)from flask import Flask, request, redirect, session, jsonify import requests import jwt import secrets app Flask(__name__) app.secret_key business-app-session-secret AUTH_CENTER http://localhost:5000 CLIENT_ID web-app-1 CLIENT_SECRET app1-secret REDIRECT_URI http://localhost:5001/callback # 與認(rèn)證中心共享的 JWT 密鑰用于本地校驗(yàn) JWT_SECRET dev-secret-key-32-bytes-long!!! JWT_ALGORITHM HS256 app.route(/protected) def protected(): 受保護(hù)頁面未登錄則跳轉(zhuǎn)認(rèn)證中心 token session.get(access_token) if not token: # 生成 state 防 CSRF state secrets.token_urlsafe(16) session[oauth_state] state auth_url ( f{AUTH_CENTER}/oauth/authorize f?client_id{CLIENT_ID} fredirect_uri{REDIRECT_URI} fstate{state} fresponse_typecode ) return redirect(auth_url) # 本地校驗(yàn)令牌 try: payload jwt.decode(token, JWT_SECRET, algorithms[JWT_ALGORITHM], issuerauth-center) return jsonify({message: 訪問成功, user_id: payload[sub]}) except jwt.ExpiredSignatureError: session.pop(access_token, None) return redirect(/protected) except jwt.InvalidTokenError: return jsonify({error: invalid_token}), 401 app.route(/callback) def callback(): 認(rèn)證中心回調(diào)用 code 換令牌 code request.args.get(code) state request.args.get(state) # 校驗(yàn) state if not state or state ! session.pop(oauth_state, None): return jsonify({error: state_mismatch}), 400 # 用 code 換令牌 resp requests.post(f{AUTH_CENTER}/oauth/token, json{ code: code, client_id: CLIENT_ID, client_secret: CLIENT_SECRET }) if resp.status_code ! 200: return jsonify({error: token_exchange_failed}), 400 data resp.json() session[access_token] data[access_token] return redirect(/protected)/protected路由先檢查 session 里有沒有令牌沒有就生成state并跳轉(zhuǎn)。state存在 session 里回調(diào)時(shí)比對(duì)防止攻擊者偽造回調(diào)請(qǐng)求。/callback路由拿到code后用requests.post調(diào)用認(rèn)證中心令牌接口注意這里是后端到后端的調(diào)用client_secret不會(huì)暴露給瀏覽器。拿到令牌后存入 session重定向回受保護(hù)頁面。4.2 本地校驗(yàn)與遠(yuǎn)程校驗(yàn)的邊界什么時(shí)候必須回認(rèn)證中心業(yè)務(wù)系統(tǒng)拿到 JWT 后有兩種校驗(yàn)方式本地校驗(yàn)和遠(yuǎn)程校驗(yàn)。本地校驗(yàn)就是用共享密鑰或公鑰驗(yàn)證簽名和過期時(shí)間不訪問認(rèn)證中心遠(yuǎn)程校驗(yàn)是調(diào)用認(rèn)證中心的/oauth/verify接口。本地校驗(yàn)的優(yōu)點(diǎn)是快、無網(wǎng)絡(luò)開銷適合高頻接口。但它有兩個(gè)邊界一是無法感知令牌被提前吊銷比如用戶登出或管理員強(qiáng)制下線因?yàn)?JWT 自包含簽發(fā)后到過期前一直有效二是如果密鑰泄露所有業(yè)務(wù)系統(tǒng)都受影響。遠(yuǎn)程校驗(yàn)?zāi)芙鉀Q吊銷問題但每次請(qǐng)求都調(diào)認(rèn)證中心認(rèn)證中心會(huì)成為瓶頸。折中方案是本地校驗(yàn)為主維護(hù)一個(gè)短期的吊銷黑名單比如 Redis 里存被吊銷的jti過期時(shí)間與令牌一致本地校驗(yàn)通過后再查一次黑名單。黑名單查詢是內(nèi)存操作比遠(yuǎn)程調(diào)用輕量得多。import redis redis_client redis.Redis(hostlocalhost, port6379, db0) def is_token_revoked(jti: str) - bool: 檢查令牌是否在黑名單中 return redis_client.exists(frevoked:{jti}) 1 def revoke_token(jti: str, expire_seconds: int): 將令牌加入黑名單過期時(shí)間與令牌剩余有效期一致 redis_client.setex(frevoked:{jti}, expire_seconds, 1)setex的過期時(shí)間很關(guān)鍵如果設(shè)得太長黑名單會(huì)無限增長設(shè)得太短令牌還沒過期黑名單就失效了。正確做法是設(shè)為令牌的剩余有效期令牌自然過期后黑名單自動(dòng)清理。4.3 多業(yè)務(wù)系統(tǒng)接入時(shí)的配置管理當(dāng)業(yè)務(wù)系統(tǒng)從兩個(gè)變成五個(gè)、十個(gè)配置管理就成了問題。每個(gè)業(yè)務(wù)系統(tǒng)都要配CLIENT_ID、CLIENT_SECRET、AUTH_CENTER地址、JWT_SECRET散落在各處的配置文件里改一個(gè)密鑰要改所有系統(tǒng)。常見做法是抽一個(gè)共享的配置中心或環(huán)境變量模板。畢業(yè)設(shè)計(jì)階段不需要上配置中心但至少要做到認(rèn)證中心的CLIENTS注冊(cè)表是唯一權(quán)威來源業(yè)務(wù)系統(tǒng)的client_secret從環(huán)境變量讀取不寫死在代碼里。下面是一個(gè)環(huán)境變量模板# 業(yè)務(wù)系統(tǒng)環(huán)境變量 export AUTH_CENTER_URLhttp://localhost:5000 export OAUTH_CLIENT_IDweb-app-1 export OAUTH_CLIENT_SECRETapp1-secret export OAUTH_REDIRECT_URIhttp://localhost:5001/callback export JWT_SECRETdev-secret-key-32-bytes-long!!!業(yè)務(wù)系統(tǒng)代碼里用os.environ.get讀取本地開發(fā)用.env文件加載生產(chǎn)環(huán)境由部署平臺(tái)注入。這樣認(rèn)證中心輪換密鑰時(shí)只需要更新環(huán)境變量并重啟業(yè)務(wù)系統(tǒng)不需要改代碼。5. 避坑與排查授權(quán)碼、令牌、跨域和時(shí)鐘的五個(gè)血淚教訓(xùn)5.1 授權(quán)碼被重復(fù)使用導(dǎo)致令牌重復(fù)簽發(fā)現(xiàn)象同一個(gè)code連續(xù)調(diào)用兩次/oauth/token兩次都返回了有效的access_token。原因授權(quán)碼存儲(chǔ)用了字典查詢但沒有刪除或者刪除操作在異常分支里被跳過。有些實(shí)現(xiàn)先校驗(yàn)client_id和過期時(shí)間校驗(yàn)通過后才刪除如果校驗(yàn)失敗就不刪除攻擊者可以反復(fù)嘗試。解決consume方法里用pop而不是get取出即刪除無論后續(xù)校驗(yàn)是否通過都不再保留。校驗(yàn)順序調(diào)整為先pop取出再校驗(yàn)client_id和過期時(shí)間校驗(yàn)失敗直接拋異常授權(quán)碼已經(jīng)不在存儲(chǔ)里了。5.2 令牌過期后業(yè)務(wù)系統(tǒng)陷入重定向循環(huán)現(xiàn)象令牌過期后業(yè)務(wù)系統(tǒng)跳轉(zhuǎn)認(rèn)證中心認(rèn)證中心發(fā)現(xiàn)用戶已登錄直接回調(diào)業(yè)務(wù)系統(tǒng)拿到新令牌但頁面還是提示未登錄反復(fù)跳轉(zhuǎn)。原因業(yè)務(wù)系統(tǒng)在/callback里把令牌存入了 session但/protected里校驗(yàn)令牌失敗后只清除了 session 里的令牌沒有清除認(rèn)證中心的登錄態(tài)。認(rèn)證中心認(rèn)為用戶已登錄直接簽發(fā)新授權(quán)碼但業(yè)務(wù)系統(tǒng)可能因?yàn)閟tate不匹配或 session 寫入失敗而拿不到令牌。解決在/protected里校驗(yàn)失敗時(shí)除了清除本地令牌還要跳轉(zhuǎn)認(rèn)證中心的登出接口或者帶上promptlogin參數(shù)強(qiáng)制重新認(rèn)證。更簡(jiǎn)單的做法是確保state生成和校驗(yàn)邏輯正確session 寫入成功后再重定向。5.3 跨域場(chǎng)景下 Authorization 頭丟失現(xiàn)象前后端分離時(shí)前端用fetch調(diào)用業(yè)務(wù)系統(tǒng)接口帶上Authorization: Bearer xxx后端收不到這個(gè)頭。原因跨域請(qǐng)求默認(rèn)不發(fā)送自定義頭瀏覽器會(huì)先發(fā)OPTIONS預(yù)檢請(qǐng)求如果后端沒有正確響應(yīng)Access-Control-Allow-Headers實(shí)際請(qǐng)求就不會(huì)帶上Authorization。解決后端 CORS 配置里明確允許Authorization頭from flask_cors import CORS CORS(app, resources{r/api/*: {origins: [http://localhost:3000]}}, allow_headers[Content-Type, Authorization], methods[GET, POST, OPTIONS])allow_headers必須包含Authorizationorigins不要用*配合credentials否則瀏覽器會(huì)拒絕。5.4 服務(wù)器時(shí)鐘偏差導(dǎo)致令牌校驗(yàn)失敗現(xiàn)象認(rèn)證中心簽發(fā)的令牌在業(yè)務(wù)系統(tǒng)校驗(yàn)時(shí)報(bào)ImmatureSignatureError或ExpiredSignatureError但令牌明明剛簽發(fā)。原因認(rèn)證中心和業(yè)務(wù)系統(tǒng)部署在不同機(jī)器上時(shí)鐘沒有同步偏差超過令牌的iat和exp容差。解決部署時(shí)用 NTP 同步時(shí)鐘。代碼層面jwt.decode可以設(shè)置leeway參數(shù)容忍一定偏差jwt.decode(token, SECRET_KEY, algorithms[HS256], leeway10)leeway10表示允許 10 秒的時(shí)鐘偏差。但這不是根治辦法生產(chǎn)環(huán)境必須同步時(shí)鐘。5.5 回調(diào)地址白名單校驗(yàn)不嚴(yán)導(dǎo)致開放重定向現(xiàn)象攻擊者構(gòu)造redirect_urihttp://evil.com/callback認(rèn)證中心校驗(yàn)通過后把授權(quán)碼發(fā)到了惡意站點(diǎn)。原因認(rèn)證中心只校驗(yàn)了client_id存在沒有校驗(yàn)redirect_uri是否在該客戶端的白名單里。解決在授權(quán)頁路由里取出client_id對(duì)應(yīng)的redirect_uris列表精確匹配redirect_uri不匹配就拒絕。不要用startswith做前綴匹配因?yàn)閔ttp://localhost:5001.evil.com會(huì)繞過http://localhost:5001的前綴檢查。精確匹配或解析 URL 后比對(duì) host 和 path。6. 進(jìn)階驗(yàn)證用腳本模擬攻擊面確認(rèn)協(xié)議真的扛得住6.1 寫一個(gè)令牌篡改檢測(cè)腳本協(xié)議設(shè)計(jì)得再好不驗(yàn)證就是紙上談兵。我一般會(huì)寫一個(gè)小腳本模擬幾種常見攻擊看認(rèn)證中心能不能擋住。第一種是篡改令牌 payload把sub改成別的用戶 ID看簽名校驗(yàn)是否失敗。import jwt import requests AUTH_CENTER http://localhost:5000 SECRET_KEY dev-secret-key-32-bytes-long!!! def test_tampered_token(): 篡改 payload 后簽名失效應(yīng)被拒絕 # 用錯(cuò)誤密鑰簽發(fā)一個(gè)令牌 fake_token jwt.encode( {iss: auth-center, sub: admin, exp: 9999999999}, wrong-secret, algorithmHS256 ) resp requests.get( f{AUTH_CENTER}/oauth/userinfo, headers{Authorization: fBearer {fake_token}} ) assert resp.status_code 401, f篡改令牌未被拒絕: {resp.status_code} print(篡改令牌檢測(cè)通過) def test_expired_token(): 過期令牌應(yīng)被拒絕 import time expired_token jwt.encode( {iss: auth-center, sub: user1, exp: int(time.time()) - 100}, SECRET_KEY, algorithmHS256 ) resp requests.get( f{AUTH_CENTER}/oauth/userinfo, headers{Authorization: fBearer {expired_token}} ) assert resp.status_code 401, f過期令牌未被拒絕: {resp.status_code} print(過期令牌檢測(cè)通過) def test_reused_code(): 授權(quán)碼重復(fù)使用應(yīng)失敗 # 先正常獲取一個(gè) code需要模擬登錄流程這里省略 # 然后連續(xù)兩次調(diào)用 token 接口 pass if __name__ __main__: test_tampered_token() test_expired_token()test_tampered_token用錯(cuò)誤密鑰簽發(fā)令牌認(rèn)證中心用正確密鑰校驗(yàn)簽名不匹配返回 401。test_expired_token簽發(fā)一個(gè)exp在過去的令牌校驗(yàn)時(shí)拋ExpiredSignatureError返回 401。這兩個(gè)測(cè)試跑通說明簽名和過期校驗(yàn)生效。6.2 授權(quán)碼一次性與 state 防 CSRF 的驗(yàn)證方法授權(quán)碼一次性驗(yàn)證需要模擬完整流程先登錄拿到code然后用同一個(gè)code調(diào)兩次令牌接口第二次應(yīng)該失敗。state防 CSRF 驗(yàn)證是構(gòu)造一個(gè)不帶state或state不匹配的回調(diào)請(qǐng)求業(yè)務(wù)系統(tǒng)應(yīng)該拒絕。def test_code_single_use(): 授權(quán)碼只能用一次 # 假設(shè)已經(jīng)通過登錄流程拿到了 code code test-code-from-login # 第一次換令牌 resp1 requests.post(f{AUTH_CENTER}/oauth/token, json{ code: code, client_id: web-app-1, client_secret: app1-secret }) # 第二次換令牌應(yīng)該失敗 resp2 requests.post(f{AUTH_CENTER}/oauth/token, json{ code: code, client_id: web-app-1, client_secret: app1-secret }) assert resp1.status_code 200, 首次換令牌失敗 assert resp2.status_code 400, 授權(quán)碼被重復(fù)使用 print(授權(quán)碼一次性檢測(cè)通過)這個(gè)測(cè)試的關(guān)鍵是resp2必須返回 400如果返回 200 說明授權(quán)碼沒有被正確消費(fèi)。state驗(yàn)證在業(yè)務(wù)系統(tǒng)的/callback里構(gòu)造一個(gè)state不匹配的請(qǐng)求應(yīng)該返回 400。6.3 壓測(cè)令牌接口看認(rèn)證中心瓶頸在哪畢業(yè)設(shè)計(jì)答辯時(shí)老師可能會(huì)問「并發(fā)怎么樣」你可以用locust或簡(jiǎn)單的ab命令壓一下令牌接口。但令牌接口依賴授權(quán)碼不能直接壓所以壓測(cè)對(duì)象選用戶信息接口或令牌校驗(yàn)接口。# 用 ab 壓測(cè)用戶信息接口100 并發(fā)1000 次請(qǐng)求 ab -n 1000 -c 100 -H Authorization: Bearer valid-token http://localhost:5000/oauth/userinfo關(guān)注兩個(gè)指標(biāo)Requests per second和Time per request。如果 QPS 上不去檢查是不是每次請(qǐng)求都在查數(shù)據(jù)庫或做復(fù)雜計(jì)算。用戶信息接口應(yīng)該只做 JWT 解碼和一次用戶查詢?nèi)绻脩舨樵兪瞧款i加緩存。認(rèn)證中心的令牌簽發(fā)接口因?yàn)樯婕笆跈?quán)碼消費(fèi)和 JWT 編碼QPS 會(huì)低一些但畢業(yè)設(shè)計(jì)場(chǎng)景下通常夠用。我自己的習(xí)慣是每做完一個(gè)認(rèn)證流程先跑一遍篡改和過期測(cè)試再跑一次授權(quán)碼一次性測(cè)試最后壓一下用戶信息接口。這三步走完協(xié)議的基本安全性就有底了。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取