解耦的藝術：現代化 Web 授權設計

JWT 權杖與應用會話分離的最佳實踐

版本/日期：v1.0 / 2025-10-10
製作單位：中央授權中心開發維運團隊

核心原則：職責分離

授權

SSO 權杖 (Token)

角色：一次性的「介紹信」
職責：證明「我是誰」、「我能做什麼」
生命週期：短暫，用完即棄
不該儲存於：瀏覽器

狀態

系統會話 (Session)

角色：持續性的「通行證」
職責：維護使用者登入後的狀態
生命週期：持續，直到登出或過期
兩種實現模式：Stateless Ticket，Stateful Session。

🎯 用「介紹信」換取「通行證」後，互動全程只認「通行證」。

情境一｜使用者單點登入 (SSO)

目標：完成登入，不承擔會話
方法：Authorization Code

SSO 權杖，後端止步：ID Token / Access Token 僅在後端處理，解析完使用者資訊後即告完成。
建立自家會話：後端驗證身分後，立即建立 app.sid。
後續溝通：瀏覽器後續僅認 app.sid，完全不接觸 SSO 權杖。

【TIPS】
1、使用「中央授權中心」授權碼模式（Authorization Code）獲得了用戶信息之后ID Token/Access Token（ SSO 權杖）任務完成。
2、建立自家會話常見方法如下：
經典伺服器端會話 (Stateful Session)，Cookie 只存一個 Session ID (app.sid)，詳細資訊存放在後端 Redis/DB。
無狀態票證 (Stateless Ticket)，將使用者資訊 (Claims) 加密後全部存入 Cookie，如 ASP.NET Core Cookie 驗證的預設模式。

情境二｜系統間 API 呼叫

目標：安全的伺服器對伺服器通訊
方法：Client Credentials

與使用者無關：整個流程只發生在伺服器端，不涉及瀏覽器。
權限最小化：每個 Access Token 都應有獨立 audience 與精準 scope。
嚴格驗證：目標 API 必驗 iss、aud、scope、exp 等聲明。

嚴禁！授權設計的反模式

❌ 將 SSO Access Token 存入 localStorage / sessionStorage（風險：XSS 竊取）。
❌ 將 SSO Access Token 放入前端 Cookie 或直接當會話使用（風險：職責混淆、仍有 XSS 風險）。
❌ 在瀏覽器直接用 fetch 攜帶 SSO Token 呼叫跨系統 API（風險：高權限憑證暴露）。

👉 正確觀念：SSO 權杖是後端機密，不是前端的玩具。

總結｜一張圖看懂授權架構

目的 (Purpose)

使用者單點登入

跨系統 API 呼叫

本系統應用會話

使用技術

Authorization Code

Client Credentials

HttpOnly Cookie

處理場域

瀏覽器 + 後端

後端限定

瀏覽器 + 後端 / 瀏覽器

核心職責

✅ 一次性身分驗證

✅ 服務間短期授權

✅ 持續性使用者狀態

關鍵心法

權杖不落地，後端換會話

後端對後端，權限最小化

應用程式的責任

Thanks

其它內容

「相信」整合開發流程快速接入單點登入 API資源交易配置說明 Token 與 Session acr_values 參數說明內省端點與權杖驗證 OIDC接入需求規範書模板多因子驗證 - 流程圖說明中央授權中心OIDC支持說明系統更新歷程