> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # UCP 藏了第四招：一組簽名，同時通過自己人跟 Web Bot Auth 兩種驗證 - URL: https://growthhackers.tw/blog/ucp-signatures-webbotauth-decode/ - Published: 2026-08-30T01:00:00.000Z - Updated: 2026-08-30T01:00:00.000Z - Description: 掃完 Cart、Catalog、Order 這些格式相似的規格後，Signatures 這頁讓我停下來：UCP 藏了一招，讓同一組簽名同時通過自己人跟 Web Bot Auth 兩種驗證。 - Author: Lewis wang - Tags: Universal Commerce Protocol, agentic commerce, Shopify, AI Agent, 電商趨勢 三篇寫完（上一篇是[UCP 藏了一個「找門市」的能力](https://growthhackers.tw/blog/ucp-location-capability-decode/)），我照上一篇的承諾，快速掃了一輪剩下的頁面：Cart、Catalog、Order、Payment Handlers、Reference。 老實說，大部分都是標準的 CRUD 規格文件，跟前面幾篇比起來沒什麼新意，我不打算硬拆成一篇一篇。但掃到 Signatures（訊息簽章）這頁的時候，我停下來了。 ## 簽章要防的四件事 UCP 用一個叫 RFC 9421（HTTP Message Signatures，HTTP 訊息簽章）的規範替每一則訊息簽名，官方講得很白話，列了四種要防的攻擊： - **冒充**：攻擊者發訊息假裝自己是合法的一方 - **竄改**：訊息內容在傳輸過程被修改 - **重放攻擊**：把攔截到的訊息重新送到不同的地方或不同的時間點 - **方法/端點混淆**：把簽過名的內容套到不同的 HTTP 方法或路徑上重放 這四條聽起來像是資安課本的標準清單，但接下來的設計，才是我想寫這篇的原因。 ## 一組簽名，同時滿足自己人跟另一套標準的驗證 業界還有另一個獨立的標準，叫 Web Bot Auth（WBA），目的是讓網站能驗證「來訪問我的這個機器人或 agent，到底是誰」。這是一個獨立的 IETF 草案，跟 UCP 是兩套不同的東西。 UCP 允許整合者把自己的簽名做成一種「雙受眾」格式：**一把金鑰、一次簽名操作、線路上只有一組簽章**，同時被 UCP 驗證方跟 WBA 驗證方接受。官方原文一句話講完：「One signature on the wire, two audiences.」 具體怎麼做到？簽署者要多做幾件事：額外帶一個 `Signature-Agent` 的標頭（跟原本的 `UCP-Agent` 並存，不是取代）、把這個欄位也納入簽章覆蓋範圍、把金鑰 ID 設成這把金鑰的 SHA-256 指紋、帶上效期參數（最多 24 小時）、最好再加一個隨機亂數防重放，最後貼一個 `tag="web-bot-auth"` 的標籤讓 WBA 那邊認得出來。 想像一下，你原本要進兩個不同的場館，各自要出示一張證件，現在有一張證件同時符合兩邊的驗證標準，安檢口只要掃一次。 有意思的是，這個互通是**單向**的。一個 UCP 簽署者的簽名可以拿去騙過（不是我說，官方用詞就是滿足）WBA 驗證方，因為 UCP 本來要求覆蓋的欄位範圍就比 WBA 的最低門檻更完整。但反過來不成立：一個只滿足 WBA 最低要求的簽名，套進 UCP 這邊會直接被拒絕，因為 UCP 檢查的覆蓋範圍更嚴格。 以前你要嘛做兩套簽名邏輯應付兩套系統，要嘛乾脆只選一邊放棄另一邊的相容性。現在有辦法一次到位，前提是你選對演算法、多帶幾個欄位。 ![官方文件截圖：一組簽名，同時滿足 UCP 跟 Web Bot Auth 兩種驗證方](https://growthhackers.tw/content/images/2026/08/inline-wba-interop-v1.png) 官方文件截圖：一組簽名，同時滿足 UCP 跟 Web Bot Auth 兩種驗證方 ## 重放攻擊，UCP 刻意不在簽章層處理 這裡有一個我覺得很清楚的架構決定。UCP 把工作拆成兩層： 簽章負責「這是誰、內容有沒有被改」；重放攻擊防護，官方刻意放到商業層的冪等鍵（idempotency key）去處理，不是簽章本身的責任。 運作邏輯是這樣：狀態變更的操作要帶一組冪等鍵，這組鍵本身也被納入簽章覆蓋範圍，攻擊者不能在不弄壞簽章的前提下偷改這組鍵。重複的請求會直接拿到快取的回應，不會被重新執行一次。 冪等鍵的要求也寫得很具體：至少 128 bits 的亂數強度（例如一組 UUID v4）、伺服器至少要保存 24 小時、內容相同的重複請求回快取結果、內容不同但鍵相同就直接拒絕（回 409 Conflict）、如果儲存這組鍵本身失敗了，系統要選擇「寧可拒絕請求」而不是照樣放行。 重點是什麼？ 只要你改了請求內容，比如換了付款方式、改了收件地址，就**必須**生一把全新的冪等鍵，不能沿用舊的去矇混過關。這條規則把「防止重複扣款」這件事做得比一般想像中更嚴謹。 ![官方文件截圖：重放防護刻意分層，簽章管身份，冪等鍵管防重放](https://growthhackers.tw/content/images/2026/08/inline-replay-protection-v1.png) 官方文件截圖：重放防護刻意分層，簽章管身份，冪等鍵管防重放 ## 一個真的會讓工程團隊踩到的坑 官方用粗體特別警告了一件事：**中間的代理伺服器、API gateway，絕對不能重新序列化 JSON body**。 原因很直接：簽章綁定的是原始的位元組，不是重新排版過的 JSON。哪怕只是欄位順序被調整、多了一個空白字元，簽章驗證都會直接失敗。 我自己這幾年看過不少團隊在導入新協定的時候，中間會多加一層 API gateway 做流量控管或格式轉換，這一類架構很容易在不知情的狀況下把 JSON body 重新序列化一次。如果你的團隊以後要接 UCP，這條規則值得貼在牆上提醒自己。 ## 金鑰怎麼換，官方寫得很具體 輪替流程是四步：先把新金鑰發布到清單裡跟舊金鑰並存，開始用新金鑰簽名，給一段至少 7 天的寬限期讓舊金鑰的簽名還能被接受，最後才把舊金鑰從清單移除。 官方建議每 90 天輪替一次。如果金鑰真的外洩了，處理順序也寫清楚：立刻把外洩的金鑰從清單移除，發一把全新 ID 的金鑰，拒絕所有用舊金鑰簽過的訊息。 這幾條合起來看，你會發現這份規格不只是定義資料格式，連「營運上這件事該怎麼做」都幫你想好了流程。 ## 哪些情境一定要簽章 **Webhook 通知一定要簽章**，因為收件的一方沒有別的辦法確認這則「商家主動推過來」的訊息是不是真的。付款授權、結帳完成的回應，官方建議簽章。購物車操作、商品目錄查詢、錯誤回應，簽章是選配的，因為這些場景本身價值低或者是唯讀操作。 ## 這件事對你來說，該做什麼？ 如果你是做技術、做產品的人： ► 如果你的團隊未來要接 UCP，先確認架構裡有沒有 API gateway 或反向代理，去查它會不會重新序列化 JSON body，這個坑現在先查比上線後除錯便宜很多。 ► 去讀 [ucp.dev 的 Signatures 規格全文](https://ucp.dev/latest/specification/signatures/?ref=growthhackers.tw)，「簽章管身份與完整性、冪等鍵管重放防護」這個分層思路，值得直接搬到你自己設計的 API 安全機制裡。 如果你是關注 SEO、關注 AI 爬蟲議題的人： ► Web Bot Auth 這類讓網站驗證機器人身份的機制，跟這一兩年「AI 該不該被允許抓你的內容、抓了要不要付費」的產業討論是同一條線上的事情，UCP 選擇跟它相容而不是自己另起爐灶，這個選擇本身就是一個值得持續關注的訊號。 ## 收尾：三篇該收，第四篇值得寫，界線是「有沒有新東西」 我這幾天寫的四篇 UCP，回頭看是一條很清楚的脈絡：第一篇測介面，第二篇讀治理，第三篇挖出一個沒人提過的能力，這一篇挖到一個真正巧妙的技術設計。 前面被問「內容真的夠完整嗎」，我後來想通一件事：完整不是把每一頁都讀過一遍，是每一次你多讀一頁，都要老實問自己「這裡有沒有真的值得告訴讀者的東西」。有就寫，沒有就跳過，不是為了湊字數硬拆成連載。 這年頭就是查證、查證、再查證，但查證的終點不是讀完所有文件，是讀到你能對讀者交代清楚為止。 --- **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。