微服務架構 #4, 如何強化微服務的安全性? API Token / JWT 的應用

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

A-Q1: 什麼是微服務架構下的安全性問題？

• A簡: 微服務多點通信，需可信驗證與授權，防竄改偽造與重放，確保來源與完整性，降低風險。
• A詳: 微服務將單體拆分為多個自治服務，跨服務呼叫遍布內外網。安全挑戰包含身分驗證（誰）、授權（可做什麼）、完整性（是否被改）、不可否認（來源可信）、與抗重放（不能被複用）。在去中心化環境下，若每次都回源查詢授權會導致高延遲與單點風險，因此常用基於密碼學的 Token 與數位簽章，讓服務獨立驗證請求的真偽，達到低耦合與高信任。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q3, B-Q1

A-Q2: 什麼是 API Token？

• A簡: API Token 是攜帶授權資訊的字串，經簽章防竄改，供服務離線驗證與授權判斷使用。
• A詳: API Token 是一段可攜帶聲明（claims）的資料，包含使用者或客戶端身分、權限範圍、有效期限等，再透過數位簽章確保完整性與來源可信。服務端收到請求後，僅憑 Token 即可驗證，不需回呼授權來源。此模式降低耦合、提升效能，廣泛用於微服務、行動與前端應用。常見實作包括自製簽章 Token 與符合標準的 JWT。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q4, B-Q2, B-Q3

A-Q3: 為什麼微服務需要去中心化的驗證機制？

• A簡: 去中心化驗證避免每次回源查詢，減少延遲與單點，提升可用性與彈性擴充。
• A詳: 在微服務架構中，若每次授權都必須連回單一認證服務，將造成高延遲、瓶頸與可用性風險。透過簽章 Token，授權與身分資訊被封裝於 Token 中，接收方可本地驗證簽章與有效期即可決策。此方式實現「離線信任」，使各服務能獨立運作，同時保持安全性與一致性，是微服務去中心化的重要實踐。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q9, B-Q19

A-Q4: 什麼是 JWT（JSON Web Token）？

• A簡: JWT 是標準化的簽章 Token 格式，含 header、payload、signature，支援多語言驗證。
• A詳: JWT 由三段組成：Header（演算法與型別）、Payload（claims，如主體、到期、範圍）、Signature（簽章）。以 Base64URL 編碼後用點號連接。簽章可用 HMAC（對稱）或 RSA/ECDSA（非對稱）。其標準化格式、跨語言工具支援與自包含特性，適合微服務與前端應用，能讓服務離線驗證請求的真偽與授權。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q5, A-Q5, B-Q18

A-Q5: JWT 與自製 Token 有何差異？

• A簡: JWT具標準與廣泛工具支援，自製Token更彈性但互通性差，維護成本高。
• A詳: 自製 Token 可完全客製資料結構與序列化（如 BSON），易於滿足特定需求；但跨語言、跨團隊互通性與維運工具較弱。JWT 依標準 RFC，具一致結構、眾多語言與框架支援、成熟安全社群實務。上線系統傾向採 JWT，除非有強需求需客製格式或既有體系採用自製方案。
• 難度: 中級
• 學習階段: 基礎
• 關聯概念: A-Q4, B-Q5, B-Q14

A-Q6: 什麼是數位簽章（Digital Signature）？

• A簡: 用私鑰對資料哈希簽章，他人以公鑰驗證，確保來源可信與內容未被竄改。
• A詳: 數位簽章以雜湊函數對資料取 Hash，再用私鑰對 Hash 簽章。驗證方用對應公鑰解簽，並自行計算資料 Hash 比對一致性。此流程提供不可否認性（確定來源）、完整性（未被改動）與防偽造（無私鑰不可偽簽）。是 Token、憑證、軟體簽署等安全機制的基礎。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, B-Q4, A-Q15

A-Q7: 什麼是 RSA？它的三個重要原則是？

• A簡: RSA為非對稱加密；用任一鍵加密，需對應另一鍵解密；私鑰保密，公鑰公開。
• A詳: RSA 使用一對密鑰（公鑰與私鑰）。核心特性為：1）用公鑰加密只能由私鑰解密；2）用私鑰加密只能由公鑰解密；3）在計算資源限制下難以從公鑰推得私鑰。此特性支撐兩大用途：機密性（公開加密、私鑰解密）與數位簽章（私鑰簽、公開驗）。正確的密鑰保護與演算法選擇是前提。
• 難度: 中級
• 學習階段: 基礎
• 關聯概念: B-Q1, A-Q16, A-Q17

A-Q8: 什麼是 Hash 函數？為何重要？

• A簡: Hash將資料映射為固定長度摘要，微改即大變；用於完整性檢查與簽章。
• A詳: 密碼學 Hash（如 SHA-256）具抗碰撞、抗預映射與雪崩效應。資料只要變更一點點，Hash 就大幅改變。簽章會對摘要簽而非原文，提升效率與安全。驗簽時重算摘要比對即可判斷是否被竄改。選擇強度足夠且未被破解的 Hash 演算法是安全基礎。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q1, A-Q6

A-Q9: 什麼是 Hash 碰撞？有何風險？

• A簡: 碰撞是不同資料產生相同摘要，將破壞完整性保證，降低簽章可信度。
• A詳: 當兩份不同資料產出相同 Hash，即為碰撞。若演算法容易碰撞，攻擊者可構造不同內容卻同摘要的資料，繞過驗證。因此需選用抗碰撞的演算法（例如避免已知弱點的 MD5、SHA-1），並持續關注社群建議，必要時進行演算法升級與金鑰輪替。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q11

A-Q10: 什麼是 Session Token？

• A簡: Session Token為短期授權憑證，內含身分與權限，簽章防改，供服務快速驗證。
• A詳: Session Token 通常在使用者或客戶端通過一次認證後簽發，包含有效期限與可用功能（如角色、標籤）。憑此 Token 呼叫其他服務時，對方可離線驗簽與檢查過期，迅速完成授權判斷。文中示例以 ClientID、ExpireDate、標籤控制可用功能，適合微服務之間的信任傳遞。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q11, B-Q2, C-Q4

A-Q11: API Key 與 Session Token 有何差異？

• A簡: API Key為長期發給應用的識別；Session Token為短期授權，攜帶動態權限資訊。
• A詳: API Key 通常在註冊時核發，長期標識客戶端，權限較固定，適合建立初始信任。Session Token 則在通過 API Key 或使用者驗證後簽發，具短效期與可攜帶豐富 claims，適合跨服務授權判斷。兩者可搭配使用：用 API Key 換取 Session Token，再憑 Token 呼叫後端服務。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q10, C-Q4, B-Q6

A-Q12: Authentication 與 Authorization 有何差異？

• A簡: Authentication驗身分「你是誰」，Authorization判權限「你能做什麼」。
• A詳: Authentication 是確認主體身分真實性，常用密碼、金鑰、憑證等。Authorization 是在已知身分下，決定可執行的操作與資源範圍。Token 可同時承載兩者：subject、issuer 表示身分；roles、scopes、tags 表示權限。清楚區分有助於設計正確的安全流程與責任分工。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, B-Q17, A-Q2

A-Q13: 為什麼 Token 要包含 ExpireDate？

• A簡: 有效期限制可降低風險、緩解撤銷難題，縮小憑證外洩與重放攻擊窗口。
• A詳: Token 自包含且離線驗證，難以集中撤銷。短期有效期可減少外洩與重放攻擊的影響，並促進定期更新權限。搭配刷新流程或重簽策略，兼顧使用者體驗與風險控制。有效期還能支援權限短時升級、時段限制等授權策略。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q13, D-Q2, B-Q12

A-Q14: 為什麼 Token 需包含 TypeName 或型別資訊？

• A簡: 型別標識可防止錯用資料結構，便於反序列化與驗證流程的安全檢查。
• A詳: 在自製 Token 中記錄 TypeName 可於解碼時比對實際型別，避免攻擊者替換成結構相似卻意圖不同的資料，強化驗證的正確性。對於多種 Token（Session、Site、Service）併行的系統，型別也協助路由不同驗證邏輯與授權規則。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, C-Q1, C-Q3

A-Q15: 公鑰與私鑰的角色是什麼？

• A簡: 私鑰用於簽章或解密且需保密；公鑰公開供驗章或加密，建立信任基礎。
• A詳: 私鑰掌握不可否認性與安全根本，必須嚴格保護。公鑰可廣泛分發，用於驗證私鑰簽章，或對資料加密僅供私鑰端解密。在 Token 場景，常以私鑰簽章、公鑰驗章，達成去中心化驗證。金鑰管理與輪替策略至關重要。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q8, B-Q11

A-Q16: 何時用私鑰加密（簽章）、公鑰解密？

• A簡: 當需證明來源不可否認與完整性時，用私鑰簽章，公鑰驗章最適合。
• A詳: 發布公告、頒發授權、核發 Token 等情境，重點在「是我發的且未改」，採私鑰簽、公開驗章。驗章方無須保密，只需持有公鑰即可驗證，適合多服務離線驗證模式。文中 SessionToken、Site/ServiceToken 皆屬此類。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q6, B-Q1, B-Q9

A-Q17: 何時用公鑰加密、私鑰解密？

• A簡: 當需保密傳輸內容時，用接收者公鑰加密，僅其私鑰能解密。
• A詳: 若目標是機密性（例如只允許指定對象讀取），發送方以接收者公鑰加密，只有接收者的私鑰能解開。也可與簽章合併：先簽章再加密，接收端先解密再驗章，兼顧機密與不可否認。Token 場景多為簽章，不涉加密原文。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q7, B-Q1, A-Q16

A-Q18: 什麼是 Replay Attack（重放攻擊）？

• A簡: 攻擊者竊得真實Token，在有效期內重複使用，繞過驗證造成損害。
• A詳: 重放攻擊不需破壞簽章，只要取得合法 Token 即可在有效期反覆使用。常見於中間人攔截、記錄重送。防護可用短效期、IP/裝置綁定、一次性 nonce/jti、時間戳與重放記錄黑名單等手段，降低可用窗口與可行性。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q13, B-Q16, D-Q8

A-Q19: 為什麼 IP 或裝置綁定能減少重放？

• A簡: 將Token與來源環境綁定，使竊得者難以偽造環境，降低重放成功率。
• A詳: 在簽發時記錄 UserHostAddress、裝置ID等環境特徵，驗證時要求一致。攻擊者需同時偽造環境才可利用被竊 Token，大幅抬高攻擊成本。此法對行動網路IP變動須審慎，可能改採裝置指紋或更穩定標識。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, C-Q8, D-Q4

A-Q20: Token 與 TLS/HTTPS 的關係是什麼？

• A簡: Token防偽改與授權；TLS保護傳輸機密。兩者互補，應同時使用。
• A詳: 簽章 Token 解決來源可信與資料完整性，但不保證傳輸過程機密性。TLS 提供通道加密，防竊聽與中間人。最佳實踐是「簽章 Token + HTTPS」，同時兼顧離線驗證與傳輸保護，將攻擊面降到最低。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q18, D-Q8, B-Q19

A-Q21: JWT 的三段結構是什麼？

• A簡: Header（演算法）、Payload（聲明）、Signature（簽章）。以點號連接並Base64URL編碼。
• A詳: Header 包含 typ=JWT、alg（如RS256）。Payload 承載標準與自訂 claims（如 iss、sub、aud、exp、role）。Signature = base64url(header). + “.” + base64url(payload) 經過簽章演算法產生。此結構標準化且可跨語言驗證。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q5, B-Q6, C-Q6

A-Q22: 為何建議優先使用標準套件如 JWT？

• A簡: 標準化減少互通風險，具完善工具、生態與實務；維運與審計更健全。
• A詳: JWT 擁有跨語言實作、現成中介軟體與安全社群審視，能快速落地並降低自製實作錯誤風險。除非確有特殊需求（如自訂序列化、極端場景），否則建議採標準以提升可維護性、可觀測性與組織內知識共享效率。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q5, C-Q6, B-Q18

A-Q23: Token 放在 HTTP Header 哪裡較合適？

• A簡: 建議用 Authorization: Bearer ；也可用自訂Header如X-SESSION。
• A詳: 通行做法是使用 Authorization Bearer 方案，獲得良好工具支援與一致性。自製範例亦使用自訂標頭（如 X-APIKEY、X-SESSION）。挑選策略時需考慮代理相容性、安全中介支援、與跨域策略。避免放在URL以防洩漏與日誌紀錄風險。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: C-Q7, C-Q4, D-Q7

A-Q24: 微服務之間如何建立信任？

• A簡: 為每服務簽發SiteToken與ServiceToken，憑公鑰驗章離線校驗來源與授權。
• A詳: 將每個服務視為節點（SiteToken：site id/url），節點間允許的調用則以邊表示（ServiceToken：from/to service id、scope、期限）。呼叫時驗章來源與目的是否匹配，再依授權聲明提供服務。此模式去中心化、可擴展，前提是嚴格金鑰管理。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q15, C-Q10, A-Q15

A-Q25: 軟體啟用序號能如何用 Token 實現？

• A簡: 將授權資訊作為claims簽章，軟體以公鑰驗章啟用對應功能與期限。
• A詳: 序號即簽章 Token，含授權類型、使用者、有效期與功能。軟體內置公鑰驗章，確保序號未被偽造或竄改。若搭配可執行檔簽章與防竄改機制，可有效對抗序號造假與二進位修改，提升整體保護強度。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: C-Q9, B-Q1, B-Q11

A-Q26: 去中心化與中心化授權有何差異？

• A簡: 中心化即時查詢權限；去中心化以簽章Token自包含授權，服務離線驗證。
• A詳: 中心化授權統一管控權限，但易成瓶頸與單點。去中心化以短效簽章 Token 分發授權，提升效能與可用性；改權需等待 Token 更新或採撤銷機制。實務多採混和：短效 Token + 重要操作回源確認/風控。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q13, B-Q20, A-Q3

A-Q27: Swagger 對 Token 開發測試有何幫助？

• A簡: 提供可視化試調與Header注入，驗證簽發/驗章流程與授權行為，提升效率。
• A詳: Swagger UI 支援設定 Authorization 與自訂標頭，能快速驗證不同角色/標籤下 API 行為與錯誤處理。搭配環境變數與範例 Token，可節省整合測試時間，輔助文件即代碼精神，縮短溝通成本。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q10, C-Q7, D-Q1

A-Q28: 為什麼私鑰保護是安全根本？

• A簡: 私鑰一旦外洩，攻擊者可偽簽任何Token；應立即輪替並撤銷影響範圍。
• A詳: 私鑰能產生有效簽章。外洩意味攻擊者可簽出看似合法的 Token 與序號。保護措施包含硬體保護（HSM/Key Vault）、嚴格權限、最小化存取面、審計與輪替策略。一旦疑似外洩，需更換金鑰對、更新公鑰、撤銷舊 Token（縮短有效期或黑名單）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q6, B-Q11, C-Q9

A-Q29: Token 內不應放哪些敏感資訊？

• A簡: 不應放明文秘密（密碼、完整身份資訊等）；必要資訊也應最小化與匿名化。
• A詳: Token 自包含且常在客戶端可見，不應放密碼、銀行資訊、隱私識別碼等。對必要資訊採最小化、以ID替代敏感明文，搭配最短必要有效期。若需保密內容，應改走後端查詢或用對稱加密封裝外層且權衡風險。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q20, B-Q18, D-Q7

A-Q30: Token 過期與更新策略應如何考量？

• A簡: 採短效期以降風險，必要時提供刷新機制或重簽，兼顧體驗與安全。
• A詳: 權衡安全與使用者體驗：短效期（分鐘至小時）降低外洩影響；對長連線可設計刷新端點或以 API Key 重簽。關鍵操作可要求再認證或動態風控，保證高度敏感情境的安全需求。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q13, D-Q2, B-Q12

Q&A 類別 B: 技術原理類

B-Q1: RSA 數位簽章如何運作？

• A簡: 對資料Hash後，用私鑰簽章；驗章方用公鑰驗證並重算Hash比對一致。
• A詳: 原理說明：先對原文計算 Hash（如SHA-256），再用私鑰對Hash簽章。驗證流程：分離簽章與資料，公鑰解簽得原始Hash，對資料重算Hash，比對一致即未被竄改。關鍵步驟：Hash、私鑰簽、分發公鑰、驗章比對。核心組件：非對稱金鑰對、Hash演算法、簽章API。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q6, A-Q7, B-Q4

B-Q2: 自製 Token 的簽發流程如何設計？

• A簡: 序列化資料、計算簽章、封裝為字串（含資料與簽章），回傳客戶端。
• A詳: 原理：TokenData以JSON/BSON序列化為資料段，計算Hash並用私鑰簽章得到簽章段，兩者Base64後以分隔符組合。關鍵步驟：準備claims（TypeName、ExpireDate、ClientID等）、序列化、私鑰簽章、組裝字串。核心組件：TokenData、TokenHelper、RSA/Hash函式庫。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q2, C-Q4, A-Q10

B-Q3: 自製 Token 的驗證流程為何？

• A簡: 解析字串分段，反序列化資料，公鑰驗章，檢查型別與有效期，通過則有效。
• A詳: 原理：拆出資料段與簽章段，資料段反序列化為TokenData，檢查TypeName與ExpireDate；用公鑰對資料段驗章（VerifyData），失敗即拒絕。關鍵步驟：格式解析、驗章、資料驗證。核心組件：反序列化器、公鑰、驗章API、例外處理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q3, D-Q1, A-Q14

B-Q4: Hash 如何保障完整性？

• A簡: 雪崩效應使微小改動導致摘要大變，搭配簽章即可偵測任何竄改。
• A詳: 原理：Hash將任意長度映射為固定長度摘要，具抗碰撞與不可逆。簽章保護Hash，驗章後重算Hash比對可識別改動。步驟：計算Hash、簽章Hash、驗章與重算、比對。核心組件：安全Hash演算法（如SHA-256/512）、簽章演算法。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q8, A-Q9, B-Q1

B-Q5: JWT 的簽章機制與流程是什麼？

• A簡: 對base64url(header.payload)用指定演算法簽章，附於第三段供驗證。
• A詳: 原理：Header聲明alg與typ，Payload承載claims。簽章計算為 signature = Sign( base64url(header)+”.”+base64url(payload) )。關鍵步驟：構造claims、選演算法（RS256等）、簽章、組裝字串。核心組件：JWT程式庫、金鑰管理、驗章中介。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q21, C-Q6, B-Q11

B-Q6: Token 內的claims應如何設計？

• A簡: 以最小化原則記錄身分、有效期與必要授權，避免敏感明文與冗餘。
• A詳: 原理：claims承載決策所需資訊。關鍵步驟：識別主體（sub/ClientID）、設定期限（exp/nbf）、標明發行者與受眾（iss/aud）、授權（roles/tags/scopes）、型別（typ）。核心組件：claims模型、驗證規則、序列化策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, A-Q14, A-Q29

B-Q7: 防竄改與防偽造如何達成？有何不同？

• A簡: 防竄改靠簽章驗證完整性；防偽造靠私鑰保護與公鑰分發，阻止偽簽。
• A詳: 原理：簽章確保資料未改（完整性）與來源可信（不可否認）。防偽造仰賴私鑰不外洩；公鑰可公開供驗章。步驟：簽章流程、驗章流程、金鑰管控。核心組件：非對稱密碼、密鑰管理、審計與輪替。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q28, D-Q6, B-Q11

B-Q8: 非對稱金鑰如何分發與管理？

• A簡: 私鑰置於安全模組，公鑰公開與版本化；配合存取控制與審計。
• A詳: 原理：私鑰僅在簽發端使用，應存HSM/Key Vault；公鑰可透過配置、JWKS端點或服務註冊中心分發。關鍵步驟：生成、保管、分發、輪替、註銷。核心組件：密鑰生命週期管理、存取控制、審計日誌。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q11, C-Q9, D-Q6

B-Q9: 去中心化驗證在微服務中如何實現？

• A簡: 以簽章Token分發授權，各服務緩存公鑰，驗章與檢查claims即可決策。
• A詳: 原理：簽章Token攜帶授權，服務無需回源即可驗證。關鍵步驟：簽發Token、分發公鑰、服務內驗章、過期與授權檢查。核心組件：JWT中介、金鑰緩存、時鐘同步與容錯處理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q3, B-Q5, B-Q12

B-Q10: IP/裝置綁定防重放的機制與限制？

• A簡: 將環境特徵納入claims並驗證一致；對行動網變動與代理需權衡。
• A詳: 原理：記錄UserHostAddress或裝置ID於Token，驗證時比對。步驟：簽發時收集特徵、驗證時取得實測值對照、失配拒絕。限制：NAT、代理、行動網IP變動；可改用裝置指紋或風險分數。核心組件：環境探知、比對策略、誤判處理。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q19, D-Q4, B-Q16

B-Q11: 金鑰輪替（Key Rotation）如何設計？

• A簡: 為公鑰加上kid版本，並行新舊簽章驗證，逐步替換與註銷舊鑰。
• A詳: 原理：新增金鑰對，簽發端改用新私鑰簽章，公開新公鑰並保留舊的以驗舊Token。步驟：生成新鑰、發布JWKS/配置、雙鑰驗證過渡、收斂舊Token、註銷舊鑰。核心組件：kid、JWKS、部署流程、審計。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: C-Q9, D-Q6, D-Q9

B-Q12: 時鐘同步與時間偏移如何處理？

• A簡: 使用NTP同步時鐘，驗證時允許小幅容差，避免早到或晚到誤判。
• A詳: 原理：Token含exp/nbf，服務時鐘不一致會導致驗證失敗。步驟：部署NTP、設置clock skew（如1-5分鐘）、記錄偏差告警。核心組件：時間服務、JWT中介參數、觀測指標。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: D-Q3, A-Q13, B-Q13

B-Q13: Token 撤銷（Revocation）有哪些策略？

• A簡: 短效期、黑名單（jti）、關鍵操作回源確認，共同降低風險窗口。
• A詳: 原理：自包含Token難即時撤銷。策略：1）短效期；2）維護撤銷清單（依jti/子串）；3）高風險操作要求回源或二次驗證。核心組件：黑名單存儲、查詢效率、TTL、刷新設計。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: D-Q8, A-Q30, B-Q16

B-Q14: JSON 與 BSON 序列化差異對效能之影響？

• A簡: BSON為二進位格式，體積更小、解析更快；JSON通用性與可讀性較佳。
• A詳: 原理：BSON以二進位緊湊表示結構，適合高效序列化；JSON文本化，易除錯與互通。選擇視場景取捨：內部高效可選BSON，自製方案中可微優；跨語言與標準工具建議採JWT（JSON）以利互通。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q5, C-Q1, C-Q2

B-Q15: SiteToken/ServiceToken 的拓撲與驗證流程？

• A簡: SiteToken綁站點身分，ServiceToken綁呼叫關係；雙檢查後決定授權。
• A詳: 原理：每站點各有SiteToken表明site id/url；站點間可調用以ServiceToken表示，含from/to service與scope。步驟：驗章SiteToken來源、核對ServiceToken端點匹配、檢查scope與期限。核心組件：claims設計、驗章流程、策略引擎。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q24, C-Q10, B-Q9

B-Q16: Nonce、jti 一次性Token如何防重放？

• A簡: 為每請求生成唯一識別並記錄使用，重複即拒絕，縮小重放可行性。
• A詳: 原理：在Token或請求中加入jti/nonce，服務端保存短期使用記錄。步驟：生成唯一值、隨請求發送、到達即查重、標記為已用。核心組件：唯一ID生成、低延遲儲存（快取/分散式）、過期清理。取捨：需伺服器狀態與資源。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q18, D-Q8, B-Q13

B-Q17: 授權粒度（roles、scopes、tags）如何設計？

• A簡: 以業務為中心定義可維護粒度，避免過粗或過細，利於審計與演進。
• A詳: 原理：授權控制需平衡易用與精準。步驟：分析業務行為、抽象角色或功能域、定義可組合scope、在Token攜帶簡潔聲明。核心組件：策略引擎、權限映射、審計日誌。文中以VIP/BAD等標籤示例。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, C-Q4, D-Q1

B-Q18: Token 放在Header、Cookie或Body的取捨？

• A簡: Header最常見；Cookie便於瀏覽器；Body僅限特定流程。需考量安全與相容。
• A詳: 原理：Header（Authorization）標準且工具支援好；Cookie受CSRF與瀏覽器策略影響；Body不利於中介攔截與快取。步驟：按客戶端型態與部署環境選擇，並配置CORS與安全標頭。核心組件：認證中介、代理/快取、瀏覽器安全策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q23, D-Q7, C-Q7

B-Q19: 簽章成本與效能如何優化？

• A簡: 緩存公鑰、異步簽發、短claims、選適當演算法與批次/快取策略。
• A詳: 原理：簽章與驗章有計算開銷。策略：縮短Payload；公鑰緩存與JWKS快取；選擇硬體加速或較快演算法；分層驗證（先檢查exp再驗章）；對高頻端點採快取或降低驗證頻率（風險評估）。核心組件：快取、池化、指標觀測。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q3, D-Q7, C-Q9

B-Q20: 與 API Gateway 的整合架構與責任邊界？

• A簡: Gateway統一驗章與基本授權，後端做細粒度決策與業務審計，分層防護。
• A詳: 原理：Gateway可做驗章、節流、黑名單、路由；後端服務針對業務上下文做細緻授權。步驟：在Gateway配置公鑰、驗章與基本claims檢查；後端再核對資源屬主與細節權限。核心組件：Gateway中介、策略服務、審計鏈路。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q9, B-Q17, D-Q1

Q&A 類別 C: 實作應用類（10題）

C-Q1: 如何在 .NET 實作 TokenData 基底類別？

• A簡: 建立抽象TokenData，含TypeName與ExpireDate，提供IsValidate覆寫檢查。
• A詳: 具體步驟：1）建立抽象TokenData，標註序列化屬性（如JsonProperty），含TypeName、ExpireDate；2）提供虛擬IsValidate檢查型別與過期；3）衍生自訂SessionToken加入claims。程式碼片段：class TokenData{ public string TypeName; public DateTime ExpireDate; public virtual bool IsValidate(){…}}。注意事項：型別一致性、時區處理、最小化claims。最佳實踐：將驗證規則集中管理與單元測試。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q14, B-Q6, C-Q3

C-Q2: 如何實作 TokenHelper.EncodeToken（簽發）？

• A簡: 序列化TokenData為位元組，私鑰簽章Hash，Base64封裝資料與簽章。
• A詳: 步驟：1）以JSON/BSON序列化TokenData；2）使用RSA私鑰SignData；3）將資料與簽章Base64並以分隔符組合為字串。程式碼：var data=Serialize(token); var sign=RSA.SignData(data,SHA256); return $”{b64(data)}.{b64(sign)}”; 注意：需確保使用私鑰、演算法一致、錯誤處理與日誌。最佳實踐：加入keyName/kid標註、追蹤ID。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q11, C-Q4

C-Q3: 如何實作 TokenHelper.DecodeToken（驗證）？

• A簡: 解析分段，反序列化資料，公鑰VerifyData，並執行IsValidate邏輯。
• A詳: 步驟：1）Split字串取得資料與簽章；2）Base64解碼資料並反序列化為TokenData；3）用公鑰VerifyData驗章；4）執行IsValidate（型別、過期、客製規則）。程式碼：var ok=RSA.VerifyData(data,SHA256,sign); if(!ok) throw InvalidSignature; 注意：健壯的例外分類（格式、驗章、授權）；防止Null或型別不符。最佳實踐：回傳明確HTTP狀態碼與錯誤碼。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, D-Q1, A-Q23

C-Q4: 如何實作簽發 SessionToken 的API？

• A簡: 驗證APIKey後，構造SessionToken（含claims/ExpireDate），用私鑰簽發回傳。
• A詳: 步驟：1）從Header讀X-APIKEY並解碼驗證；2）建立SessionToken：ClientID、UserHostAddress、roles/tags、ExpireDate；3）EncodeToken簽發字串；4）以201或200回傳。程式碼：var apikey=GetHeader(“X-APIKEY”); var session=CreateSession(apikey); return Encode(“SESSION”,session); 注意：設定合理有效期、最小權限、記錄審計。最佳實踐：限制頻率與風險檢測。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q10, A-Q11, C-Q7

C-Q5: 如何在API服務端驗證Token（ASP.NET）？

• A簡: 於中介或Filter攔截，解碼驗章、檢查claims與過期，失敗回401/403。
• A詳: 步驟：1）建立DelegatingHandler/ActionFilter或Middleware；2）讀取Authorization或X-SESSION；3）DecodeToken並驗章；4）檢查ExpireDate與角色；5）將claims放入HttpContext；6）失敗回傳適當狀態。程式碼：var token=Decode(…); if(!token.IsValidate()) return 401; 注意：時鐘容差、例外處理、觀測與日誌。最佳實踐：可與Swagger/自測工具集成。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, A-Q23, D-Q1

C-Q6: 如何用JWT（RS256）發行與驗證（.NET）？

• A簡: 使用JWT庫設定claims與RS256，用私鑰簽發；服務端載入公鑰驗章與授權。
• A詳: 步驟：1）載入私鑰（X509或PEM）；2）構造ClaimsIdentity與SecurityTokenDescriptor（iss/aud/exp/roles）；3）用JwtSecurityTokenHandler.CreateToken並WriteToken；4）驗證端配置TokenValidationParameters（ValidateIssuerSigningKey、公鑰、ClockSkew）。程式碼：handler.WriteToken(token)。注意：kid與輪替、公鑰來源安全。最佳實踐：使用中介與配置化管理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q11, A-Q22

C-Q7: 如何在HTTP Header安全地攜帶Token？

• A簡: 使用Authorization: Bearer，或自訂標頭；避免放URL，配合HTTPS傳輸。
• A詳: 步驟：1）客戶端將Token放入Authorization Bearer；2）服務端從Header讀取並驗證；3）設置CORS與安全標頭；4）避免寫入URL或日誌。程式碼：req.Headers.Authorization=new(“Bearer”,token); 注意：Header長度限制、跨域與代理相容。最佳實踐：最小化Token尺寸與有效期。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q23, D-Q7, C-Q10

C-Q8: 如何實作IP綁定來降低重放攻擊？

• A簡: 簽發時寫入UserHostAddress，驗證時比對來源IP，不符即拒絕。
• A詳: 步驟：1）在Auth服務擷取客戶端IP寫入claims；2）在資源服務驗證Token後，讀取當前請求IP比對；3）允許可信代理（X-Forwarded-For）處理；4）失配回403。程式碼：token.UserHostAddress==requestIP。注意：行動網變動、NAT、代理。最佳實踐：改用裝置ID或風險分數、與短效期搭配。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q19, B-Q10, D-Q4

C-Q9: 如何管理金鑰與輪替（Key Vault + kid）？

• A簡: 金鑰放安全倉儲，簽發端取私鑰；公鑰標kid發布；過渡期雙鑰驗證。
• A詳: 步驟：1）在Key Vault/HSM創建金鑰對；2）簽發服務以托管身分存取私鑰；3）對外發布JWKS含kid與公鑰；4）更新簽發kid、雙鑰並存；5）收斂舊Token後移除舊鑰。程式碼：依平台SDK存取金鑰。注意：權限邊界、審計、旋轉計畫。最佳實踐：自動化輪替與回滾。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q11, D-Q6, D-Q9

C-Q10: 如何用Swagger測試受保護API？

• A簡: 在Swagger設定BearerAuth或自訂Header，輸入Token後執行試調並檢視回應。
• A詳: 步驟：1）在OpenAPI方案定義securitySchemes(Bearer)；2）標註需要授權的路由；3）啟動UI並輸入Token；4）執行請求觀察401/403/200行為；5）驗證角色切換與過期處理。程式碼：在SwaggerGen中AddSecurityDefinition與Requirement。注意：避免在公共環境暴露有效Token。最佳實踐：提供範例與沙盒環境。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q27, C-Q7, D-Q1

Q&A 類別 D: 問題解決類（10題）

D-Q1: 驗證簽章失敗怎麼辦（Invalid signature）？

• A簡: 症狀401/403；多因公鑰不匹配、演算法不同或Token被改；檢查金鑰與流程。
• A詳: 症狀：驗章失敗、日誌顯示InvalidSignature。可能原因：使用錯誤公鑰/舊金鑰、alg配置不一致、Token被改、Base64解析問題。解決：核對kid與公鑰版本、統一演算法、重新簽發、檢查序列化與傳輸。預防：金鑰管理與版本化、CI/CD測試覆蓋驗章。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q11, C-Q3, C-Q6

D-Q2: Token 過期導致無法存取怎麼處理？

• A簡: 症狀401/Expired；刷新或重簽；調整有效期與時鐘容差，優化體驗。
• A詳: 症狀：Expired或Token過期拒絕。原因：exp已到、時鐘偏差。解決：實作刷新流程或重簽；伺服器允許小容差；使用者重新登入。預防：合理有效期、NTP同步、監控過期錯誤比率。對高風險操作仍建議短效。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q12, A-Q30, B-Q13

D-Q3: 跨服務時鐘不同造成驗證錯誤怎麼辦？

• A簡: 症狀剛簽發即無效；配置clock skew與NTP同步，確保時間一致性。
• A詳: 症狀：nbf未到或exp已過。原因：服務器時鐘不同步。解決：部署NTP、在驗證中設定ClockSkew（如2-5分鐘）、記錄偏差告警。預防：基礎建設層面確保時鐘一致、容器/虛擬機時區與同步策略正確。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q12, C-Q6, A-Q13

D-Q4: IP 綁定導致合法使用者被誤擋怎麼辦？

• A簡: 症狀403/IP不符；考慮代理與行動網，改用裝置ID或放寬策略。
• A詳: 症狀：不同網段或代理轉發下被拒。原因：行動網IP變化、NAT/Proxy。解決：信任代理（X-Forwarded-For）、改綁裝置ID、允許城市/ASN範圍、調整風控。預防：在場景適配時審慎評估IP綁定、提供回退驗證機制。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q10, C-Q8, A-Q19

D-Q5: HS256/RS256混用導致驗證錯誤怎麼辦？

• A簡: 症狀alg不匹配；統一演算法與金鑰策略，禁用不必要alg，明確配置。
• A詳: 症狀：alg不支援或驗章失敗。原因：服務端預期RS256，客戶端用HS256（對稱）；或反之。解決：協定統一alg、清理舊配置、更新文件與SDK。預防：在驗證器強制允許的alg白名單，避免alg切換攻擊。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, C-Q6, B-Q7

D-Q6: 私鑰外洩如何緊急處置？

• A簡: 立即輪替金鑰、撤銷舊Token、審計影響面並強化保護與告警。
• A詳: 症狀：異常許可或驗證通過偽Token。處置：生成新鑰、更新簽發端使用、發布新公鑰，舊公鑰保留僅限驗舊Token；縮短舊Token有效期或黑名單撤銷；通告影響面。預防：最小權限、HSM/Key Vault、審計與輪替制度化。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q8, B-Q11, A-Q28

D-Q7: Token 太大導致Header超長怎麼辦？

• A簡: 症狀431/被代理拒絕；精簡claims、改用短ID、壓縮或改傳輸位置。
• A詳: 症狀：HTTP 431或網關拒收。原因：claims過多、冗長字串。解決：移除不必要claims、以ID代替長文本、縮短kid與iss/aud、必要時放在Cookie或Body（評估風險）。預防：設計初期控制Payload長度並監控。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q18, B-Q19, C-Q7

D-Q8: 如何診斷並緩解重放攻擊？

• A簡: 症狀重複請求具同Token；引入jti/nonce與短效期、記錄查重、風險阻擋。
• A詳: 症狀：相同Token短時間多次使用。原因：攔截/token重用。解決：加入jti、在快取記錄已用清單、短效期、IP/裝置綁定、TLS全程。預防：威脅模型與監控，可疑模式自動封鎖、告警與風控挑戰。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q16, A-Q18, C-Q8

D-Q9: kid 不匹配導致找不到公鑰怎麼辦？

• A簡: 症狀驗章找不到key；同步JWKS、緩存刷新與回退策略，校正配置。
• A詳: 症狀：找不到對應kid的公鑰。原因：JWKS未更新、緩存過舊、配置誤差。解決：刷新JWKS快取、允許短暫回退至舊kid、檢查部署次序。預防：發布流程保證先發公鑰再換簽發kid，並監控錯誤率。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q11, C-Q9, D-Q1

D-Q10: 開發/測試/正式環境密鑰混用如何排查？

• A簡: 症狀跨環境驗章失敗；分環境金鑰與配置隔離，檢查來源與發行者。
• A詳: 症狀：本地OK，上線失敗。原因：用錯環境金鑰或iss/aud不符。解決：為各環境獨立金鑰與配置，標示清楚；驗證時檢查iss/aud與kid。預防：CI/CD強制環境變數與密鑰隔離、測試覆蓋跨環境案例。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: C-Q9, B-Q5, B-Q9

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是微服務架構下的安全性問題？
  • A-Q2: 什麼是 API Token？
  • A-Q3: 為什麼微服務需要去中心化的驗證機制？
  • A-Q4: 什麼是 JWT（JSON Web Token）？
  • A-Q6: 什麼是數位簽章（Digital Signature）？
  • A-Q7: 什麼是 RSA？它的三個重要原則是？
  • A-Q8: 什麼是 Hash 函數？為何重要？
  • A-Q10: 什麼是 Session Token？
  • A-Q11: API Key 與 Session Token 有何差異？
  • A-Q12: Authentication 與 Authorization 有何差異？
  • A-Q13: 為什麼 Token 要包含 ExpireDate？
  • A-Q21: JWT 的三段結構是什麼？
  • A-Q22: 為何建議優先使用標準套件如 JWT？
  • C-Q4: 如何實作簽發 SessionToken 的API？
  • C-Q5: 如何在API服務端驗證Token（ASP.NET）？
• 中級者：建議學習哪 20 題
  • B-Q1: RSA 數位簽章如何運作？
  • B-Q2: 自製 Token 的簽發流程如何設計？
  • B-Q3: 自製 Token 的驗證流程為何？
  • B-Q5: JWT 的簽章機制與流程是什麼？
  • B-Q6: Token 內的claims應如何設計？
  • B-Q9: 去中心化驗證在微服務中如何實現？
  • B-Q11: 金鑰輪替（Key Rotation）如何設計？
  • B-Q12: 時鐘同步與時間偏移如何處理？
  • B-Q13: Token 撤銷（Revocation）有哪些策略？
  • B-Q18: Token 放在Header、Cookie或Body的取捨？
  • B-Q19: 簽章成本與效能如何優化？
  • C-Q1: 如何在 .NET 實作 TokenData 基底類別？
  • C-Q2: 如何實作 TokenHelper.EncodeToken（簽發）？
  • C-Q3: 如何實作 TokenHelper.DecodeToken（驗證）？
  • C-Q6: 如何用JWT（RS256）發行與驗證（.NET）？
  • C-Q7: 如何在HTTP Header安全地攜帶Token？
  • A-Q18: 什麼是 Replay Attack（重放攻擊）？
  • A-Q19: 為什麼 IP 或裝置綁定能減少重放？
  • D-Q1: 驗證簽章失敗怎麼辦（Invalid signature）？
  • D-Q2: Token 過期導致無法存取怎麼處理？
• 高級者：建議關注哪 15 題
  • B-Q10: IP/裝置綁定防重放的機制與限制？
  • B-Q15: SiteToken/ServiceToken 的拓撲與驗證流程？
  • B-Q16: Nonce、jti 一次性Token如何防重放？
  • B-Q17: 授權粒度（roles、scopes、tags）如何設計？
  • B-Q20: 與 API Gateway 的整合架構與責任邊界？
  • C-Q8: 如何實作IP綁定來降低重放攻擊？
  • C-Q9: 如何管理金鑰與輪替（Key Vault + kid）？
  • C-Q10: 如何用Swagger測試受保護API？
  • A-Q24: 微服務之間如何建立信任？
  • A-Q25: 軟體啟用序號能如何用 Token 實現？
  • A-Q26: 去中心化與中心化授權有何差異？
  • A-Q28: 為什麼私鑰保護是安全根本？
  • D-Q4: IP 綁定導致合法使用者被誤擋怎麼辦？
  • D-Q6: 私鑰外洩如何緊急處置？
  • D-Q8: 如何診斷並緩解重放攻擊？