前言 Preface
在公司業務擴張的過程中，並沒有一個完整的授權機制。遊戲上架到多個不同的平台，我們的授權與認證機制是一種很「碎片化」的狀態。 這體現在許多部份：
- 遊戲如何幫特定用戶進行遊戲設定
- 當新的客戶到來，內部如何管理這個客戶的資料
- CMS 的授權機制怎麼進行整合
- 多個服務之間如何讓彼此信任
這種不一致性增加了維護成本：
- 權限邊界模糊：特定遊戲伺服器在不同客戶環境下的操作權限
- 整合效率低：新專案對接交易系統時，需重新討論授權方式
- 安全性弱點：缺乏統一的憑證輪替與撤銷機制
- 專案管理混亂：每個客戶的 CMS 都是獨立的專案
我想要導入以「授權」為核心的基礎設施規格。不僅僅是單一服務的設計說明，而是用來約束與協調多個服務之間如何進行身份驗證、授權判斷、權限傳遞與審計。這份規格的讀者預設為工程師與系統設計者，而非產品使用者。文件中的名詞、流程與假設，會直接影響後續服務的實作方式與整體系統的安全模型。
本文件的目的是定義一套統一的身分識別與授權標準。透過引入許多工程上的實際標準，實現漸進式的架構轉型。這套系統將確保不論是遊戲主控台的設定、還是核心交易系統的扣款，都能在可控且好維護的前提下運行。
備註
本文章撰寫時，基於以下假設：
- 公司內部有自己的 H5遊戲，會跟許多平台簽約，在他們的首頁投放我們的遊戲。
- 簽約的平台會把我們的遊戲拿去再給子平台上架，子平台也會做一樣的事情，依此類推。
- 公司也有平台，可能會上架別人的遊戲
- 第三方平台會想要調整我們的遊戲設定(若有開放)，且設定是根據遊戲、幣別都不同的。
- 這些設定有些要求更旗下的代理商硬性遵守，有些允許調整
- 入口網站的可見度要區分，同樣切分平台與幣別。
要處理的問題如下：
- 權限怎麼管理，系統設計原則是否涵蓋這些需求？
- 其他平台的用戶可以玩我們的遊戲，那這個用戶隸屬於誰？
- 遊戲的設定應該存在中央的組態，還是每個遊戲自行維護？
- 如果有一項服務跨越遊戲，例如隨機抽一位在線上的玩家派獎(Jackpot)，那這個服務的授權怎麼設計？
- 不同平台在同一個幣別下，看到的首頁遊戲清單是否不同？