登入鑑權方案怎麼設計提示詞（Session 與 JWT 怎麼選、刷新令牌、退出登入與強制下線、令牌存儲位置）
新項目要做登入鑑權，或者現有方案出了問題（退出登入後令牌仍然有效、改密碼後舊裝置還能用、令牌被盜用）時用：AI 根據客戶端類型和安全要求在會話與 JWT 之間做選擇，設計令牌有效期、刷新與輪換、吊銷和存儲方式，並給出關鍵代碼和安全檢查清單。
通用大模型 對話模型通用
你是一名身份認證與安全方面的後端架構師。請為我的項目設計登入鑑權方案。 - 客戶端類型：[客戶端類型]（例：同域 Web、App、小程式、第三方調用） - 用戶規模與部署：[規模與部署]（例：10 萬用戶，多實例部署） - 安全要求：[安全要求]（例：改密碼後所有裝置下線，後台可強制下線） - 登入方式：[登入方式]（例：帳號密碼、短訊驗證碼、第三方登入） - 技術棧：[技術棧] - 現有方案（如果有）： [現有方案說明] 請輸出： 1. 方案選擇：服務端會話與 JWT 各自的優缺點（吊銷難易、橫向擴展、跨域與移動端、性能），結合我的客戶端類型和安全要求給出推薦。說明「JWT 天然無狀態」這一說法在需要吊銷時的侷限。 2. 令牌設計（如果使用令牌）： - 訪問令牌短期有效，刷新令牌較長期有效；刷新令牌每次使用後輪換，並檢測舊刷新令牌被重複使用（可能被盜）的情況； - 令牌中只放必要的標識，不放敏感資料； - 簽名算法與密鑰管理，校驗時固定允許的算法。 3. 存儲位置： - Web 端：使用帶安全屬性的 Cookie（僅 HTTP 訪問、僅 HTTPS、同站策略）與放在瀏覽器本地存儲的風險對比，以及對應的跨站請求偽造防護； - App 端：使用系統提供的安全存儲。 4. 吊銷與下線：退出登入、修改密碼、後台強制下線、可疑登入時，如何讓已發出的令牌或會話失效（例如令牌版本號、黑名單、刪除會話）。 5. 登入接口的防護：限制失敗次數與頻率、統一的錯誤提示（不暴露「用戶不存在」）、密碼使用專門的慢哈希算法存儲。 6. 給出關鍵代碼：登入、刷新、校驗中間件、退出登入。 7. 安全檢查清單。
高亮處換成你自己的內容：[客戶端類型]、[規模與部署]、[安全要求]、[登入方式]、[技術棧]、[現有方案說明]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[客戶端類型] 是選型的關鍵：同域的 Web 應用使用服務端會話加 Cookie 往往最簡單也最安全；有 App、小程式或第三方調用時，令牌方案更合適。[安全要求] 寫清楚是否需要「改密碼後所有裝置下線」「後台強制下線」，這直接決定了是否需要服務端儲存狀態。
常見坑：
- 選擇 JWT 後才發現退出登入、改密碼都無法讓舊令牌失效，只能等它自然過期。需要吊銷能力時，必須在服務端儲存一些狀態。
- 把令牌放在瀏覽器本地存儲，一旦頁面存在跨站腳本漏洞，令牌就會被直接讀走。
- 刷新令牌有效期很長又不輪換，被盜後攻擊者可以長期冒充用戶。
追問技巧：追問「加上第三方登入（如微信、Apple）後，帳號綁定和合並怎麼設計」，或「設計異地登入提醒和裝置管理頁面」。
示例輸出
示例，僅供參考（同域 Web + App，節選）
推薦：Web 端使用服務端會話加安全 Cookie；App 端使用短期訪問令牌（15 分鐘）加可輪換的刷新令牌（30 天）。兩端共用一張會話表，用於吊銷。
| 場景 | 處理方式 |
|---|---|
| 退出登入 | 刪除當前會話記錄；App 端同時作廢該會話的刷新令牌 |
| 修改密碼 | 用戶表中的令牌版本號加 1，所有舊令牌校驗失敗 |
| 刷新令牌被重複使用 | 判定為可能被盜，作廢該用戶的整個令牌家族並要求重新登入 |
js
// 校驗中間件（節選）：校驗簽名後，再比對令牌中的版本號
const payload = jwt.verify(token, PUBLIC_KEY, { algorithms: ['RS256'] }) // 固定允許的算法
const user = await users.findById(payload.sub)
if (!user || user.tokenVersion !== payload.ver) throw new Unauthorized()同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～