微服務架構 #4, 如何強化微服務的安全性? API Token / JWT 的應用
摘要提示
- 微服務安全: 服務拆分後需以正確架構與密碼學確保跨服務的信任與資料完整性
- API Token: 以數位簽章建立可離線驗證的授權票證，避免服務間即時查詢的依賴
- RSA 數位簽章: 私鑰簽名、公開鑰驗證，確保來源不可否認與內容未被竄改
- Hash 重要性: 以訊息摘要對抗微小變動，避免碰撞確保驗章有效
- 土炮實作: TokenData/TokenHelper 約百行程式，實作簽發、驗證、過期與授權檢核
- 重放攻擊對策: 在 Token 綁定環境特徵（IP/裝置 ID）與時效，抑制 Replay Attack
- JWT 應用: 採 RFC 規範的 header/payload/signature 格式，生態系工具完善
- 啟用序號: 將授權資訊簽章即是序號；結合程式碼簽章強化對抗反編譯竄改
- 分散式信任: 以 SiteToken/ServiceToken 管控服務身分與授權邊界
- 密鑰治理: 私鑰保管是安全基石，避免自創非標準機制，採用成熟演算法與框架
全文重點
文章以微服務架構下的安全挑戰為出發點，指出當系統拆分為多個服務後，彼此間如何建立信任、確保資料在不安全的網路環境中傳遞仍不可竄改，是架構設計的核心。作者先用真實世界的「車票」類比，說明「可驗證來源與內容」即可大幅降低跨系統即時溝通的需求，進而引入密碼學的數位簽章概念：以 RSA 私鑰對資料的 Hash 做簽章，接收端用對應的公鑰還原並比對 Hash，若相符即可確認來源與完整性。
接著作者示範一個輕量「土炮」API Token 實作：以 TokenData 表達授權內容（含到期日、功能權限等），TokenHelper 則負責序列化資料、計算 Hash、以私鑰簽章並合併為 Token；驗證時再拆解、以公鑰驗章、重算 Hash 比對與執行自訂規則（如是否過期）。這實作只需約百行程式碼，即能支撐 A 服務簽發 Session Token，B 服務離線驗證並據以授權，避免每次都回呼 A 服務查詢。
針對常見的重放攻擊（Replay Attack），作者主張在 Token 中綁定可辨識的環境特徵（如 IP、裝置唯一 ID）與嚴格時效，讓竊取到的 Token 難以在不同環境重用。雖然 IP 在行動網路場景未必穩定，但可改綁更合適的識別資訊，以小成本提升防護。
作者進一步介紹 JWT：相較自製 Token，JWT 有標準化格式（header/payload/signature）、支援多種演算法與眾多語言與框架整合，適合正式上線採用。原理與土炮實作一致，但生態系完善、互通性高，更利於跨技術棧合作。
在延伸應用方面，作者分享兩個典型場景：其一是軟體啟用序號，將授權資訊簽章即成序號，啟動時用公鑰驗證並啟用對應功能；若需對抗反編譯繞過驗證，則結合程式碼簽章。其二是雲端分散式系統的「站點身分」與「服務授權」管理：以 SiteToken 綁定服務節點身分（site id/url），以 ServiceToken 管控調用邊界與權限，服務間在入口即做身分與授權雙重檢查。
在 Q&A 中，作者釐清「用私鑰簽名、公鑰驗證」與「用公鑰加密、私鑰解密」各自的適用情境；亦說明同時要求機密性與不可否認性時可組合雙方金鑰。最後總結：微服務強調去中心化，安全機制更需建立在正確的密碼學原理與標準框架上，避免自創不成熟方案；同時，密鑰管理（特別是私鑰保護）是所有安全設計的關鍵。
段落重點
API Token 原理說明
作者以跨站服務信任為情境，說明在網際網路環境中，傳遞經客戶端的資料極易被攔截與篡改，若每次都要求來源服務即時回應驗證，成本高且不穩定。借用「車票」的隱喻，只要票面有可靠的防偽機制且載明使用範圍，驗票端即可離線驗證。對應到軟體世界，即是以數位簽章確保「來源真實」與「內容未改」，讓被調用服務能不依賴即時通訊來建立信任，達到低耦合。
API Token 要解決的難題
透過 A（付款/授權）與 B（商品/服務）分離的案例，若資料在客戶端被任意竄改，例如用 100 元的授權去兌換 1000 元的服務，將造成損失。需求核心是「B 能自主確認資料確為 A 簽發且未被改動」，並在互聯網的不可信通道下仍可驗證。為此需要一種可離線驗證的安全憑證機制，避免每次都回到 A 查詢，這正是 API Token 的角色。
RSA 數位簽章
說明 RSA 的基本原則與簽章流程：先對原始資料計算 Hash，再用私鑰加密 Hash 形成簽章；驗證時以公鑰解出 Hash，並對收到的原始資料重新計算 Hash 比對，一致則通過。Hash 的性質（微小變動即大幅改變、碰撞機率低）讓簽章能有效偵測內容被改。如此，即便資料傳輸全被攔截，攻擊者也無法在不持有私鑰的情況下偽造對應簽章。
API Token 實作 (土炮版)
以 C# 示範 TokenData/TokenHelper：TokenData 定義類型、到期日與自訂驗證規則；SessionToken 擴充建立時間、ClientID、來源 IP 與功能權限旗標。簽發流程為序列化（文中用 BSON）、以私鑰簽章、再將資料與簽章打包；驗證則為解包、反序列化、以公鑰驗章、執行 IsValidate（如未過期、型別一致）。A 服務核發 Session Token，B 服務以公鑰離線驗證後授權執行。攻擊者即使讀懂內容，無私鑰仍無法構造有效簽章或修改權限標記（如將 BAD 改為 VIP）。
阻擋 Replay Attack
重放攻擊是竊取合法 Token 在有效期內重用，無須破解簽章。對策是在 Token 綁定環境特徵並縮短時效：例如將使用者 IP（或更穩定的裝置唯一 ID、電話號碼等）寫入 Token 並簽章，B 端驗證通過後再比對現場環境是否一致，不符則拒絕。此法不依賴伺服器端狀態即可提升難度，雖 IP 在行動網路不穩定，仍可用合適的唯一識別替代，達成低成本高效的風險緩解。
JWT (Json Web Token)
JWT 以 RFC 規範定義 header、payload、signature 三段格式，支援多種演算法與廣泛語言/框架，便於跨系統集成。其本質與文中的土炮 Token 相同：可攜帶授權聲明、以簽章確保完整性與來源不可否認。相較自行實作，JWT 擁有成熟工具鏈與更佳互通性，較適合作為正式上線方案；開發者可聚焦於權限設計與密鑰治理，而非底層編解碼細節。
延伸應用
將 Token 思維擴展到兩個場景。1) 軟體啟用序號：把授權資訊（功能、期限、客戶）包成 Token 並簽章即為序號，啟動時以公鑰驗證即可；若要抵抗反編譯繞過檢查，須結合程式碼簽章，雙重保護才完整。2) 雲端分散式驗證：以 SiteToken 綁定站點身分（site id/url），以 ServiceToken 管控調用邊界（caller/callee/service id/權限），服務入口同時做身分與授權檢查。關鍵在於妥善保管私鑰，集中簽發以杜絕未授權節點或私服。
以下開放 Q & A
澄清公私鑰使用情境：公鑰加密、私鑰解密用於「只有指定收件者可讀」；私鑰簽名、公鑰驗證用於「證明發訊者身分、內容未改」；若同時要求機密性與不可否認性，則可先以私鑰簽名、再以收件者公鑰加密的組合流程。Token 簽章屬於第二種情境，因此以私鑰簽名、公鑰驗證是正確作法。
結論
微服務去中心化讓安全機制更必須建立在正確的密碼學與標準框架上。以數位簽章的 Token（或 JWT）能在不可信通道與離線場景下建立跨服務信任；再配合綁定環境與時效降低重放風險。實務上應採成熟演算法與生態系工具，並將私鑰保護視為最高優先，避免自創不成熟方案導致系統性風險。
Reference
提供讀書會錄影、投影片與 GitHub 範例程式碼連結，利於讀者進一步查閱原理、操作示範與完整實作細節。
資訊整理
知識架構圖
- 前置知識：學習本主題前需要掌握什麼？
- 基礎密碼學概念：非對稱金鑰（RSA）、雜湊函式（SHA-256 等）、數位簽章原理
- Web/HTTP 基礎：HTTP Header、RESTful API、Client/Server 流程
- JSON 序列化/反序列化（含 BSON 概念）
- 微服務與分散式系統基本觀念：服務之間的信任與授權
- 開發實務：.NET Web API（或對應語言/框架）、常見 JWT 套件使用
- 核心概念：本文的 3-5 個核心概念及其關係
- 數位簽章與驗證：以 RSA 私鑰簽章、公開金鑰驗證，確保訊息「來源可驗、內容未被竄改」
- API Token/Session Token：將授權資訊序列化後簽章，跨服務攜帶並驗證
- JWT（Json Web Token）：RFC 規範的 Token 格式（header/payload/signature），多語言套件支援
- Replay Attack 與防護：綁定環境特徵（如 IP 或裝置 ID）+ 有效期，降低重播攻擊風險
- 金鑰管理：私鑰保護、公開金鑰分發、金鑰輪替與信任邊界 關係：用數位簽章實作 API Token；JWT提供標準化格式與生態；透過防重播與金鑰治理提升在微服務間的信任強度。
- 技術依賴：相關技術之間的依賴關係
- 底層：雜湊演算法（SHA-256 等）→ RSA 非對稱金鑰 → 數位簽章/驗證
- 資料表示：JSON/BSON 序列化 → 打包 Token 資料
- 標準格式：JWT 規範（header/payload/signature; base64url 編碼）
- 傳輸與集成：HTTP Header 攜帶 Token → API Gateway/服務端中介層驗證
- 開發工具：JWT libraries（多語言）、Swagger 用於測試、雲端託管（如 Azure API Apps）
- 應用場景：適用於哪些實際場景？
- 微服務間的跨服務授權與信任建立（A 簽發，B 驗證）
- 行動/前端調用後端 API 的會話與權限控制（短期 Session Token）
- 軟體啟用序號與授權啟用（離線驗證，僅需 public key）
- 分散式系統/多站點架構中的 Site/Service 級權限拓撲管理
- 第三方整合、API 市集、B2B 接口的輕量授權
學習路徑建議
- 入門者路徑：零基礎如何開始？
- 理解雜湊、RSA 與數位簽章的直覺模型（圖解/比喻）
- 用現成 JWT 套件簽發與驗證一個最小可行 Token（含 Exp、Iss、Aud）
- 在本地兩個簡單服務（Auth 與 API）間透過 HTTP Header 傳遞與驗證 JWT
- 使用 Swagger/Postman 驗證流程與常見錯誤
- 進階者路徑：已有基礎如何深化？
- 自行實作「序列化 → 簽章 → 打包」「驗證 → 反序列化」的 Token Helper（理解土炮版）
- 設計 Claims/Scopes 與 RBAC/ABAC 權限模型
- 實作 Replay 防護（IP/裝置 ID 綁定、Nonce/Timestamp）
- 研究金鑰管理：金鑰輪替（kid/JWKS）、私鑰保護（HSM/KMS）、公鑰分發
- 實戰路徑：如何應用到實際專案？
- 建立專責 Auth 服務（簽發 JWT），各微服務統一用中介層驗證
- Token 設計：設定合理過期、綁定客戶端屬性、最小化必要 Claims
- 佈署至雲端（如 Azure），在 API Gateway/反向代理加上驗證與節流
- 加入監控與稽核：驗證失敗率、重播疑慮、金鑰輪替健康檢查
- 撰寫風險與災難演練：私鑰外洩應變、撤銷策略、版本遷移
關鍵要點清單
- 數位簽章原理: 用私鑰簽章、用公鑰驗證，確保來源與完整性（不可否認性） (優先級: 高)
- RSA 金鑰對: 私鑰嚴格保護、公鑰廣泛分發，信任鏈的基石 (優先級: 高)
- 雜湊函式（SHA-256）: 少量變動導致完全不同摘要，避免碰撞以確保驗證可靠 (優先級: 高)
- Token 結構設計: 序列化資料（JSON/BSON）+ 簽章，攜帶最小必要資訊 (優先級: 高)
- JWT 三段式: header/payload/signature 的標準格式與 base64url 編碼 (優先級: 高)
- 驗證流程: 解析 → 驗簽 → 自訂業務驗證（如過期、類型）三步驟不可少 (優先級: 高)
- 有效期限（exp）: 短期 Token 減少風險並便於權限變更快速生效 (優先級: 高)
- 防重播（Replay）: 綁定 IP/裝置 ID、加入 timestamp/nonce，服務端校驗唯一性 (優先級: 高)
- Claims/授權模型: 以 Claims/Scopes 表達權限，最小權限原則 (優先級: 中)
- 金鑰管理與輪替: 使用 kid/JWKS、計畫性輪替、私鑰置於 HSM/KMS (優先級: 高)
- 公鑰分發: 透過可驗證來源的端點提供公鑰，確保服務端可正確驗簽 (優先級: 中)
- 傳輸層安全: 全程 TLS，避免 Token 在傳輸中被竊聽取得 (優先級: 高)
- 錯誤處理與例外: 清楚區分格式錯誤、簽章無效、過期與未授權 (優先級: 中)
- Token 儲存與傳遞: 放在受控的 HTTP Header，避免長期保存與跨站暴露 (優先級: 中)
- 服務間信任拓撲: SiteToken/ServiceToken 建模服務與邊之授權關係 (優先級: 中)
- 軟體授權啟用: 使用簽章序號做離線驗證，搭配程式碼簽章抵禦篡改 (優先級: 中)
- 可觀測性與稽核: 記錄驗證事件、失敗原因、來源特徵以利偵測攻擊 (優先級: 中)
