架構設計 Architecture

系統應該採用分層式安全與身分架構，將不同性質的問題放在特定的小範圍內解決。連線安全、身分建立、請求驗證與業務決策，這些問題的變動速度、失效風險與效能要求並不相同。

除此之外，猶如網路的 4 層或 7 層理論，系統可以維持一致的安全模型，獨立修改各個組件。身份系統、閘道與業務服務可以分別調整實作與部署方式，而不破壞整體行為的可預期性。

連線安全層 (Transport Layer)

基於憑證與 TLS：

所有能直接對系統發起連線的伺服器，無論是內部團隊、子系統或商業夥伴，都必須持有特定的憑證。此層的責任僅限於確認「連線端點是否為受信任的設備或服務實體」，不涉及使用者或業務語意。憑證的 Subject、SAN 或 Extension 可用於識別組織、系統類型或環境，但不直接映射為應用層權限。

此層級是第一道防線，直接用於隔離不信任的實體。

完成連線的實體，必須出示特定的憑證、Client Secret 等資訊，讓伺服器可以證明其身分，並發放對應的 Token。簽發 Token 時，會根據其身分，注入角色、授權範圍以及其他的必要資訊。

此層級負責處理 Principal、Token 管理策略、RBAC 的語義映射。

備註

該層不一定是個實體的服務，也可以整合到共用的 Middleware Library，如果公司原本有授權的系統，可以移到此處進行整合。

所有的 API 請求（包含交易系統、主控台 API）都經過統一的 Gateway。它負責檢查 Token 的合法性，並利用 JWK 進行簽章驗證，擋掉無效請求。這裡不處理角色判斷、授權範圍、資料庫等議題。

此層級負責處理「結構化」的邏輯：

與具體的服務沒有關係，類似「轉換層」的概念，確保所有的路由、後端服務看到統一的 Token 資訊。

業務執行層包含交易系統與各類後端服務。這些服務假設所有進來的請求，已完成連線驗證與身分驗證。服務本身不處理 Token 的合法性驗證，也不管理金鑰。僅從 Token 的 Claims 中提取必要資訊，例如：

此層級負責處理業務語意，授權判斷與資料隔離邏輯必須在此層完成：資料庫查詢條件自動注入 WHERE 子句、操作前檢查角色是否允許、禁止 A 用戶存取 B 用戶的資料。

注意

服務層又稱商業邏輯層，是唯一一個只能由負責專案的開發人員自行處理的，因為我無法確定你的商業邏輯到底包含了那些規則。

分層本身不會是效能瓶頸，比方說特定的 Critical Path Ex. 交易系統，只要確認好邊界、快取等機制，還是可以維持住高效能的模式，未來的伺服器開發者指導會進一步討論。