任務內容

全站授權地基（JWT）的用法體檢與改善建議。這是評估案、非 bug 修復——結論分「做對的」「該修的」「技術債」三層。核心結論：機制（撤銷 / 演算法 / 傳輸）合格甚至偏好，但 token 壽命設定有明顯問題，投報率最高的一改只需動 config。

• 來源：FR-047 SEC 桶處理期間，user 要求評估 JWT 用法是否合適。
• 範圍：config/config.py、common/middleware/jwt_mw.py、jedi-login login_token_service / login_token_domain_service、jedi-common auth context。

現況/需求釐清

✅ 做對的（不用改）

• 傳輸走 header、非 cookie → 天生無 CSRF 面。
• 撤銷是真的能撤：login_tokens 是白名單 + fail-closed（jti 查不到即當已撤銷擋下），非假撤銷；且 per-jti 撤銷（登出一裝置不踢其他分頁）。
• HS256 + secret 從 env（JWT_SECRET），無硬編。
• Agent JWT（FR-039）用 RS256 非對稱 + 60 秒 TTL，與使用者 JWT 分離，設計正確。
• X-Tenant-ID 切租戶有驗證（middleware 驗 tenant 必在 user.tenants 內，非盲信 header）。

🔴 主要問題：token 壽命 + access/refresh 分工（實查 config/config.py）

1. access token 8.3 小時太長（業界慣例 15～60 分）。access 每請求都送，壽命越長、外洩後可被盜用窗口越大。目前靠每請求查 DB 白名單止血，但那是補救、非源頭控制。開發環境 3.5 天更誇張。
2. refresh 僅比 access 長 2.4 倍（正式環境），access/refresh 分工形同虛設。正常應是 access 短（分鐘級頻繁換）+ refresh 長（天/週級）。現況兩者差不多長，白拆成兩個。

🟠🟡 其他技術債

• login_tokens 白名單無限長大：每次登入 / refresh / refresh 產生的新 access 都寫一列，查無清理排程。表膨脹會拖慢每請求的撤銷檢查（同 user-log#6 分區 retention 沒排程的病）。
• 每受保護請求打 2 次 DB：user_lookup_loader 重查整個 user（roles/tenants/org_units join）+ 撤銷白名單查。好處是改角色即時生效 / 能撤銷，壞處是每支 API 先吃兩 query。與「長壽 access」自相矛盾（既然每次都查 DB，access 短一點不會多花多少）。
• JWT is_admin claim 沒被用、且與 context 的語意不同：token claim is_admin＝any(role.is_admin==1)；UserContextDTO.is_admin＝user.is_super_admin（每請求 DB 重算）。token 那個是死 claim + 命名撞車。
• claims 內含 login_name / nickname：JWT 只是 base64、非加密，持有 token 即可讀出。敏感欄位不該放 claims。