描述

驗證流程總覽

在驗證流程中，Licensee（營運商）扮演 Player（玩家）的入口與閘道角色。主要挑戰在於，如何在不暴露敏感憑證的情況下，安全地將玩家的會話（Session）從 Licensee 平台交接至 Game Provider 的環境。

本章節定義用於驗證 Licensee 身分，也包含了Game Provider 如何與 Licensee 之間進行 Service-To-Service(S2S) 的認證，確保發出的請求由合作的Licensee發出。

Game Provider 收到請求時，驗證流程確保 Game Provider 能夠信任請求確實來自合法的 Licensee。

驗證請求來源：只有持有共享 client secret 的 Licensee 能生成正確的簽章，Game Provider 可據此確認請求來自合法合作方。
確保請求內容未被竄改：簽章基於請求中的指定欄位計算；若傳輸過程中任何被簽章的內容被修改，驗證將失敗。
防止請求偽造：攻擊者即使攔截 HTTP 請求，也無法在未知 client secret 的情況下重新生成有效簽章。
阻止重放攻擊：配合專用的 HTTP Header 欄位，可限制請求有效時間與檢測重複請求

為滿足不同安全需求與技術能力，提供幾種驗證模式：

使用公私鑰機制進行請求簽章。Licensee 使用私鑰簽署請求，Game Provider 透過對應的公鑰驗證簽章。此模式不需要共享秘密金鑰，擁有更高安全性或審計要求較高的整合場景。

雙方共享一組 CLIENT_SECRET，請求透過 HMAC-SHA256 產生簽章。Game Provider 以相同金鑰重新計算並驗證簽章。此模式實作簡單、計算成本低，適合高頻率的 Service-to-Service 請求。

Licensee 將會被分配一組 API_KEY 作為識別憑證，請求時透過 HTTP Header 傳送。此模式部署與整合成本最低，但僅提供基礎的客戶端識別能力，通常需要搭配 IP whitelist 或其他保護機制使用。

驗證模式	安全性	支援算法
非對稱式簽章	不需共享秘密金鑰，支援請求完整性驗證與完整追溯性	`ECDSA`
對稱式簽章	需共享 `client secret`，可驗證請求來源與完整性	`HMAC-SHA256`
API Key	僅提供客戶端識別，不具備請求簽章與完整性保護	N/A

建議使用的驗證機制

我們強烈建議使用非對稱式簽章搭配 ECDSA 簽章作為請求驗證機制。所有請求必須由 Licensee 使用其專屬私鑰進行數位簽章。對應的公鑰僅註冊於 GameProvider，用於驗證簽章。

在非對稱式加密模型下，Licensee 始終完全掌控其私鑰。GameProvider 僅保存對應的公鑰進行驗證，因此在技術上無法偽造或冒充由 Licensee 發出的請求。