這章要學會什麼
- 說明為什麼
/mcp不能沿用網站的登入憑證，而要用專門簽發、有期限、指定用途的通行證。 - 在網站裡套用一套標準授權服務：登入同意頁、換發通行證，並在後臺登記一個測試用的 AI 助理程式。
- 讓
/mcp主動提供「去哪裡辦通行證」的說明資訊，並驗證通行證的簽章、簽發者、用途、期限。 - 用通行證裡「誰簽的」加「簽給誰」這一對資訊，對應到平台裡真正的會員，而不是直接相信程式自己回報的使用者編號。
- 用官方測試工具完成「探索→登入→同意→換證→呼叫」整套流程，並實測沒登入、過期、用途不符的通行證都會被拒絕。
先備知識
要先完成第 9 章：/mcp 目前用暫時的固定憑證。要知道什麼是「用點分成三段的一長串英數字」——這是本章通行證的基本樣子，暫時知道這樣就夠了。
觀念白話講
網站登入憑證，跟 AI 助理的通行證，是兩種不同的東西
| 比較 | 網站登入憑證 | AI 助理的通行證 |
|---|---|---|
| 誰拿著 | 會員的瀏覽器 | AI 助理程式 |
| 怎麼取得 | 在登入頁輸入帳密 | 會員在同意頁按「允許」後，AI 助理程式用授權碼換取 |
| 能用在哪裡 | 整個網站 | 只能用在指定的資源（本章就是 /mcp） |
| 有效期 | 8 小時，操作中會自動延長 | 10 分鐘，到期就失效 |
| AI 助理知道會員密碼嗎 | — | 完全不知道，密碼只輸入在平台自己的登入頁 |
實測結果很直接：拿著網站登入憑證去呼叫 /mcp，會得到「未認證」的拒絕——/mcp 只認專門的通行證。
從「被拒絕」到「拿到通行證」的整個過程
整個過程中，AI 助理程式從頭到尾都碰不到會員的密碼——密碼只會輸入在平台自己的登入頁面上。這個過程裡有幾個關鍵的安全機制：
- 轉回網址要先登記過：授權完成後要轉回哪個網址，必須是事先登記過、逐字相同的網址，攻擊者不能隨便把授權碼導去別的地方。
- 證明「換證的人」就是「當初發起授權的人」：命令列這類程式沒辦法安全保存密鑰，所以改用一種「先產生一個隨機值，只送出它的雜湊值，真正換證時才交出原文」的驗證手法，半路上偷到授權碼的人因為沒有原文，換不到通行證。
- 指定用途：AI 助理程式必須明確指定「這張通行證要用在哪個資源」，給另一個用途的通行證拿來呼叫
/mcp必須被拒絕。
通行證裡到底裝了什麼
這張通行證只簽章、不加密，內容包含：誰簽的（授權服務本身）、簽給誰（授權服務眼中的使用者代號）、給哪個資源用、到期與簽發時間、哪一個 AI 助理程式、同意了什麼權限範圍。因為有簽章保護，任何人都不能偷偷篡改內容——只要改一個字，簽章就對不上，/mcp 會直接拒絕。
「簽給誰」這個代號，為什麼還要再查一次對應表
通行證裡「簽給誰」這個代號看起來就像是會員編號，為什麼還要多查一次對應表？因為這個代號只在簽發它的那個授權服務裡才有意義。將來如果接上別的登入服務（例如公司或學校自己的登入系統），別的授權服務也可能簽出剛好一樣的代號，那其實是另一個人。所以平台只相信「誰簽的」加「簽給誰」這一組合起來才唯一的對應關係，而這個對應是在會員按下「允許」那一刻建立的——那一刻會員剛用網站帳密登入過，平台才能確認這個代號真的對應到這位會員。
老師示範做了什麼
示範情境：在後臺登記一個測試用的 AI 助理程式；程式自動找到授權服務，會員在瀏覽器裡登入並按下「允許」，然後成功列出並呼叫工具；最後逐一示範沒登入、用途不符、過期、對應不到會員這幾種情況都會被正確拒絕。
老師接著逐一示範反向情境：未登入就打開授權網址，會先被導去登入頁；在同意頁按「拒絕」，程式會收到「會員拒絕授權」的結果；指定錯誤的用途，會在授權那一步就直接被拒絕；拿到的通行證如果指定的用途不是 /mcp，呼叫時會被拒絕；通行證過期後呼叫一樣被拒絕；把對應表裡的紀錄手動刪掉，同一張原本合法的通行證會變成「知道你是誰，但找不到對應會員」；只帶網站的登入憑證去呼叫 /mcp，一樣被拒絕。每一種被拒絕的情況，網站的紀錄裡都會寫出清楚的拒絕原因。
自己動手的步驟
步驟一：套用標準授權服務套件
加入授權服務套件，讓它使用跟平台同一個資料庫存放授權相關的協定資料（登記過的程式、授權碼、通行證）。設定授權服務要簽發的「誰簽的」固定寫死（不能讓它依請求網址自動猜測，否則會跟後面的對應表對不起來）；只開放「授權碼」這一種流程，而且強制要求前面提到的雜湊驗證手法；設定通行證的有效期限。
步驟二：登記測試用的 AI 助理程式
後臺表單檢查完規則之後，同時登記到授權服務的協定資料，跟平台自己的一張「已登記程式」清單。轉回網址的規則是：一律允許加密網址；只有明確指向「自己這台電腦」的網址才允許不加密——因為命令列、桌面程式的轉回網址本來就是使用者自己電腦上的臨時網址。這類程式一律視為「無法安全保存密鑰」，強制要求雜湊驗證手法。
步驟三：授權端點與同意頁
授權服務驗證完程式身分、轉回網址、雜湊驗證資料、用途之後，才把請求交給我們自己的頁面——我們只需要決定「這個人是誰、他同不同意」。這裡是唯一會用到網站登入憑證的地方：確認登入的會員身分後，把「這位會員的編號」寫進要簽發的通行證內容裡；按「允許」的那一刻，同時建立「誰簽的＋簽給誰」對應到這位會員的紀錄。
步驟四：/mcp 認證改法
把 /mcp 改成接受這種標準通行證：驗證交給授權服務套件本身去做（簽章、簽發者、用途、期限），並且在沒帶通行證時主動附上「去哪裡辦」的說明資訊。另外寫一段「身分轉換」邏輯，在通行證驗證通過之後，用「誰簽的＋簽給誰」去查對應表，查到才補上會員編號、放行；查不到就停在原地，讓下一關的授權判斷回傳「知道你是誰，但沒有對應的會員」。
步驟五：測試用戶端改用標準授權流程
把第 9 章那組暫時固定的通行憑證，換成套件內建的標準授權設定：指定程式識別碼、轉回網址、要求的權限範圍，以及「怎麼讓會員登入」這一段（可以是自動開啟瀏覽器、等會員操作完成，也可以是自動化腳本代替瀏覽器完成登入與按下允許）。
常見錯誤
| 症狀 | 原因 | 怎麼處理 |
|---|---|---|
呼叫 /mcp 得到內部伺服器錯誤 | 驗證方案的設定沒有正確轉交給授權服務套件本身去驗證 | 明確指定「驗證要轉交給哪個方案」 |
| 授權網址回報「指定的資源無效」 | 用戶端指定的資源沒有先在授權服務裡登記，或這個程式沒有被授予使用這個資源的權限 | 登記資源、並確認程式的權限清單裡包含這個資源 |
| 自己寫腳本送出同意表單得到失敗 | 只抓了看得到的隱藏欄位，漏掉了防偽造請求的隱藏欄位 | 把這個欄位也一併抓出來送出 |
/mcp 回應說「用途不符」 | 通行證指定的用途跟實際連線的網址不一致 | 確認雙邊設定的資源網址完全一致 |
怎麼驗收＋反向驗證
- 完成整套授權流程：測試工具在瀏覽器裡登入、按下允許，畫面顯示授權完成。
- 能列出並呼叫工具：主控台正確列出工具，成功呼叫並附有追查代碼；呼叫紀錄裡的會員與程式名稱都正確。
- 未登入被拒絕：不帶通行證呼叫得到拒絕並附上說明資訊；未登入時開授權網址會先被導去登入頁；只帶網站登入憑證一樣被拒絕。
- 過期的通行證被拒絕：把有效期設得很短，等過期後再呼叫，必須被拒絕。
- 用途不符的通行證被拒絕：指定另一個資源換出的通行證，拿來呼叫
/mcp必須被拒絕。 - 反向驗證：刪除對應表裡的紀錄後，同一張原本合法的通行證變成「找不到對應會員」；同意頁按「拒絕」要正確回報拒絕；轉回網址沒有登記過的程式要被拒絕登記。