核心概念 Concept

在正式說明授權的機制之前，必須先讓所有的開發同仁有一致性的共識，為此我想先定義公司業務的範圍，我基於以下的假設規劃授權系統：

1. 有自己的遊戲，會上架到其他平台
2. 對成功上架的遊戲，我們會提供後台系統供客戶查詢遊戲紀錄與調整遊戲設定(每個用戶是獨立的)
3. 除了提供給每個用戶個別的後台系統，我們也應該要有自己的主控台系統
4. 交易系統理應是通用的，但遊戲伺服器是獨立的
5. 高併發、對帳精確度要求高、經常需要與第三方平台對接

基於以上的假設，我有幾個核心規劃：

1. 身分識別：建立通用的識別機制，並提出如何相容舊的認證機制
2. 環境分隔：在Production環境中要有嚴格的認證機制，但是Development環境下，可以較為寬鬆
3. 資料設計：針對博弈平台的特性（遊戲設定、分潤比例、額度控制、風險控制），進行資料庫的規劃
4. 方便調整：如果用戶想要通過 API 調整遊戲的設定，提供一系列的指南指導開發者如何暴露遊戲的設定修改方法
5. 觀測性：整合 OpenTelemetry，用以追蹤用戶在一次交易中，經過了哪些元件
6. 強隔離性：基於憑證、子網路切割、負載平衡與代理伺服器等機制，把敏感性的元件隔離在最深層的範圍

除了要達成以上的目標，還要確保實作不與主流的理論衝突。為此，應該在設計時，引用多項工程、學術上的理論與規範。

認證 (Authentication)

確認「請求的發出者是誰」。系統在此階段只關心身分是否可被驗證，不判斷這個身分能不能做任何事。

提示

一個 API 請求攜帶 JWT。服務驗證簽章正確、未過期，並能解析出sub=yhchen。到這一步為止，只能確定請求者是 yhchen，尚未決定他能存取的資源範圍。

授權 (Authorization)

判斷「這個身分在此情境下是否被允許執行某個行為」，授權依賴已完成的認證結果，並結合資源、行為與上下文進行判斷。

提示

yhchen 請求刪除 MZ_project。服務檢查其角色與屬性，發現該使用者僅有 read 權限，因此拒絕刪除操作。yhchen 已經通過認證確定是一個合法的用戶，但是他嘗試執行不合法的操作。

多租戶隔離 (Multi-Tenancy)

確保不同租戶之間在資料、權限與影響範圍上彼此獨立。系統假設同一套服務會同時為多個租戶運作，但任何行為都必須被限制在租戶邊界內。

顯式信任 (Trust Chain)

信任必須透過可驗證的機制逐段建立，而不是隱含假設。「信任」需要能被檢查、驗證與撤銷。

注意

我們是否應該假定，來自內網的請求就必定是安全的？或者只要是從我們的 CMS 客戶端發出請求，就直接讓其通過

服務間的身分識別 (S2S Identity)

用來識別「是哪一個服務在呼叫另一個服務」，而非代表使用者。它通常不涉及使用者互動，重點在於服務本身的可驗證身分與最小權限。

---

以上五個核心議題，會在之後的文件中討論，但它們構成了幾個核心決策：

先確認請求者是「誰」，這個用戶「能做什麼」；這個用戶「在隸屬於哪個客戶/平台」；並透過「可驗證的機制」，區分該請求來自「某個使用者還是某個服務」。