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