OAuth 是什麼？AI 工具要你授權時，到底發生了什麼事

OAuth 是一套授權框架，讓應用程式可以不拿到你帳號密碼，就取得有限度存取你資料的權限。這套機制由 IETF 在 2012 年 10 月以 RFC 6749 標準化，規範了資源擁有者、用戶端應用與服務端三方之間怎麼核發、傳遞與查驗存取憑證。你在 AI 工具上看到「連結 Google 帳號」「授權存取行事曆」的畫面，背後走的就是這套流程：工具向你證明它要什麼，Google 向你確認身分，你按下同意，Google 才發給工具一把有範圍、有期限的鑰匙。

為什麼 AI 工具特別常要你授權？因為 AI 助理要替你做事，光會聊天不夠。整理行程要讀你的日曆，回覆會議邀約要寫入日曆，分析信件要讀 Gmail，盤點網站狀態要拉 Search Console 的資料。這些資料都鎖在你的帳號裡，工具要嘛請你手動匯出貼上，要嘛走正式的授權流程拿到存取權。前者做不到自動化，後者就是 OAuth 出場的時機。換句話說，AI 工具的「代理」性格越強，需要碰你帳號資料的機會越多，你遇到同意畫面的頻率就越高。

這篇以 RFC 6749、Google 官方的 OAuth 2.0 與 Workspace 開發者文件、OpenID Foundation 說明、MCP 規格授權章節與 Google 帳號說明為本，查證時間為 2026 年 10 月 22 日。文中沒有實際操作特定 AI 工具的紀錄，流程示意都會標明；各服務的介面名稱與選項可能隨版本調整，動手前以當天畫面為準。

快速重點：OAuth 讓你「給對方一把只能開一扇門、效期有限的鑰匙」，整串鑰匙（帳號密碼）則留在自己手上。登入與授權是兩件事，前者驗證你是誰，後者決定對方能做什麼。看同意畫面先檢查三件事：誰要存取、唯讀還是可修改、資料拿去做什麼。授權可以撤回，但對方已複製走的資料不會跟著消失。MCP 規格在 2025 年 6 月 18 日版採用 OAuth 2.1 保護工具連線，工具協定與授權協定是分工關係，不是競爭關係。

OAuth 解決的根本問題：密碼不能交給別人

要理解 OAuth 在解決什麼，先回到沒有它的年代。你想用一個相片編輯網站修 Google 相簿裡的照片，網站說：給我你的 Google 帳號跟密碼，我幫你抓照片進來修。你把密碼打進去了，接下來發生的事你完全看不到：網站拿到的是帳號的完整控制權，能讀信、能看雲端硬碟的合約、能改密碼救援信箱。你想收回權限，唯一的方法是改密碼，而且你根本不知道對方有沒有把密碼存下來、轉給誰。

這個模式在工程圈有個難聽但傳神的名字，叫密碼反模式。問題有三層。第一層是授權範圍：帳號密碼是全有或全無的憑證，沒有「只給你看相簿、不能動其他東西」的中間地帶。第二層是可撤回性：密碼一旦交出去，對方的存取權就跟你綁在一起，你只能靠改密碼來一刀兩斷，所有用這組密碼的服務同時被斷線。第三層是責任歸屬：對方拿到密碼之後做的一切事，在服務端看起來都像「你自己登入」，出了事你很難自清。

RFC 6749 對這個問題的回應，是把「你是誰」與「對方能做什麼」拆開，再塞進一個三方結構裡。你是資源擁有者，資料鎖在你的帳號裡；申請存取的應用程式是用戶端；真正保管資料的服務（例如 Google）是資源伺服器，旁邊再站一個授權伺服器負責核發憑證。在本文走的那種瀏覽器導向流程裡，用戶端從頭到尾接觸不到你的密碼，它拿到的是一種叫 access token 的短期憑證，這份憑證對應已核准的範圍，服務端逐次查驗：這個憑證有效嗎？要求讀的是日曆，憑證核准了日曆嗎？核准的是唯讀還是可寫入？任何一關不過，請求就被擋下。

把舊模式與新模式擺在一起，差異就很具體。舊模式下，你交出的是萬能鑰匙，對方存取多久、碰到哪些資料，你沒有儀表板可看，也沒有開關可按。OAuth 模式下，你交出的是一張有指名用途的臨時通行證：範圍由 scope 限定，效期由 token 壽命限定，撤回權在你手上，而且撤回不必改密碼，其他服務不受影響。AI 工具的授權場景只是這個老問題的最新版本：工具要替你動的資料越核心，這套「不交密碼、給有限鑰匙」的機制就越重要。

這條紅線不是工程圈的默契，是服務方白紙黑字的規定。Google 帳號說明把話講得很直：不要與第三方應用程式或服務分享 Google 帳號密碼，密碼一旦共用，對方就取得帳號的完整存取權，可能危及帳號安全；相對安全的做法就是透過正式的授權機制，只開放部分的帳號資料。下次再遇到哪個工具請你「輸入 Google 密碼」而不是跳出官方登入頁，你已經知道那不只是體驗差，是整個安全模型都被跳過了。

登入與授權是兩件事：OpenID Connect 站在哪一層

很多人把「用 Google 帳號登入」與「授權工具存取資料」當成同一件事，其實它們回答的是兩個不同的問題。登入回答「你是誰」，術語叫身分驗證，證明你真的是這個帳號的主人。授權回答「對方可以拿你的什麼、做到什麼程度」，術語就叫授權。兩件事常常在同一個流程裡連續發生，先驗證身分、再確認授權，但職責分明，混在一起談就容易誤判風險。

一個只做登入、不碰資料的按鈕，背後通常是疊在 OAuth 之上的 OpenID Connect。OpenID Foundation 的說明把它定位為以 OAuth 2.0 為基礎的互通身分驗證層：驗證使用者身分，取得使用者基本資料（以 Google 帳號登入為例，就是名稱、電子郵件地址、個人資料相片）。所以當你在某個網站按「使用 Google 帳號登入」，你做的其實是一次身分驗證加一個最小範圍的授權，對方拿到的通常只是你的基本資料，不是信箱或硬碟的鑰匙。想深入「用社群帳號登入網站」這件事在電商場景的實作與取捨，站上的WooCommerce 社群登入設定指南有完整的拆解。

界線畫清楚之後，看同意畫面會精準很多。畫面上如果只出現「查看你的基本個人資訊」，這是登入導向的授權，風險集中在對方怎麼用你的身分識別資料。畫面上如果出現「查看及編輯你所有的 Google 日曆活動」，這是資料存取導向的授權，風險集中在資料外流與誤操作的破壞面。同一個按鈕流程裡，兩種授權可能同時出現，按同意之前值得逐條讀，後面會給具體的檢查方法。

兩種場景對照著看更清楚。情境一，你在某內容網站按「使用 Google 帳號登入」，畫面只列基本資料，按下去你拿到的是會員身分，網站拿到的是你的名字與信箱，你寄放在 Google 的其他東西一概不動。情境二，你在 AI 助理裡按「連結 Google 帳號」，畫面列出日曆範圍，按下去之後助理每天讀你的行程。前者把 Google 當身分證用，後者把 Google 當資料庫用，你交出去的東西差了好幾個數量級。名稱相近的兩個按鈕，成本結構完全不同，這是「登入與授權是兩件事」最實用的記法。

完整走一遍：AI 工具整理 Google 行事曆，授權流程發生了什麼

以下用一個示意情境走完整流程：你裝了一個 AI 助理，想讓它每天早上讀你的 Google 日曆、整理成一份今日行程摘要。情境是假設的，但每一步都對應 Google 官方文件定義的流程。看懂這一輪，你再看任何 AI 工具的授權畫面，都知道螢幕上每個訊息站在流程的哪個位置。

1. 開發者先向 Google 登記應用程式。在你看到任何畫面之前，AI 工具的開發者已經在 Google 端建立了一個應用程式專案，取得用戶端憑證，並且預先宣告這個應用會要求哪些 scope，例如讀取日曆。這一步是事前申報。
2. 你按下「連結 Google 帳號」，瀏覽器跳到 Google 官方頁面。關鍵細節：這個畫面不是 AI 工具自己畫的，是 Google 的頁面。看網址就能確認。工具在這一步能做的是「發起請求並說明要什麼」，不能替你按同意；不過 RFC 6749 的安全章也提醒，這種「把人導去某個頁面輸入密碼」的形態天生容易被釣魚利用，第三方仍可能偽造外觀相似的頁面，所以輸入任何憑證前，先核對網址是不是 Google 的官方網域，這是規格等級的建議，不是多餘的謹慎。
3. 你在 Google 的頁面登入並選帳號。如果你有多個 Google 帳號，這一步會要你挑一個，這是身分驗證。密碼打在 Google 自己的頁面上，AI 工具全程接觸不到。
4. 同意畫面列出要求的權限範圍。畫面會逐條寫清楚，例如「查看及編輯你所有的 Google 日曆活動」。這份清單對應工具本次授權請求指定的 scope，你要做的是逐條讀完再決定，後面「三個檢查」那一節會展開。
5. 你按下同意，Google 核發 access token 給應用程式。這把鑰匙不是你的密碼，是由 Google 發給應用、受核准範圍與效期限制的憑證；而 RFC 6749 對它的要求是在傳輸與儲存時都當機密保管，因為規格並沒有保證服務端能分辨「出示憑證的就是原核發的應用」，憑證一旦外洩，拿到的人同樣能持著它存取，安全性靠的是保管，不是「只有原應用會用」的假設。
6. AI 工具帶著 token 呼叫日曆 API。工具向 Google 的日曆服務提出讀取請求，請求裡附上 token。服務端查驗：token 是否有效、是否過期、要求的操作是否在核可範圍內。
7. 查驗通過，服務回傳資料。日曆服務把行程資料交給工具，工具再整理成摘要給你。之後每天早上的自動讀取，都是重複第六步與第七步，不需要你再次登入。

流程裡有一個位置值得停下來看：密碼的暴露面。整個流程中，你的密碼只出現在第三步的 Google 官方頁面，AI 工具拿到的是第五步的 token。這正是 RFC 6749 設計的核心交易：用「範圍有限的憑證」換掉「全有的密碼」。代價是你要看得懂同意畫面上的範圍聲明，因為你按下的同意，決定的就是那把鑰匙能開幾扇門。

還有一個實務細節：授權是「每個工具各自一份」。你讓 A 助理讀日曆，不代表 B 助理也能讀；B 要存取，自己要走一遍同樣的流程。這聽起來像重複麻煩，實際上是安全設計：每一份授權獨立存在、獨立撤回，盤點時才能逐一檢視，斷捨離時才能精準下刀。

按下「取消」或只給部分權限，會發生什麼

流程裡你不是只有「同意」一個選項。按下取消或關掉畫面，授權不成立，工具拿不到憑證，通常會退回未連線狀態或請你改用其他方式。比較少人知道的是「部分核可」的存在：應用宣告的範圍是一回事，你最終核可的範圍可能是子集，Google 的流程文件也因此提醒開發者，取得 token 後要檢查實際核可了哪些範圍，再決定對應的功能行為，不能假設「我申請的全拿到了」。

這個設計對使用者端有一個直接的保護效果：功能與權限的對應關係是誠實的。一個工具申請了五項權限、你只給了兩項，它就只能在兩項範圍內做事，硬碰超出範圍的請求會被服務端擋下，使用者看到的通常就是那個功能故障或要求補授權。所以當一個工具「看起來能動但某個功能一直要你重新授權」，先別急著按重新授權，回頭看它這次多要了什麼範圍，答案往往就在那條新增的權限裡。

拒絕的成本也值得知道。同意畫面不是簽一次就永遠不再出現：Google 的文件也建議開發者在使用者真正需要某項功能時，才逐次要求需要的範圍，所以工具之後要求更大範圍時，會再跳一次同意流程。不過重新出現授權畫面不一定是擴權，也可能是原本的憑證已經失效，或管理政策使然；正確的判斷方法是比較這次畫面列出的範圍與先前核可的範圍，確認是不是多了東西。這表示你手上的控制權不是一次用盡的，每一輪新增範圍都要再過你這一關，把「又跳授權畫面」當成停下來核對範圍的提示，而不是系統在找麻煩，心態上會從煩轉為警覺。

access token 與 refresh token：為什麼授權一次之後不必再登入

流程走完後你大概會注意到一件事：只有第一次要登入按同意，之後工具每天讀日曆都沒再吵你。這背後是兩種憑證的接力，理解它們的生命週期，你會知道授權的效期怎麼算，也會知道哪一天它會失效。

access token 是直接拿來敲門的憑證。依Google 官方的 OAuth 2.0 授權文件，基本流程是取得憑證、向授權伺服器索取 access token、確認核可的範圍、把 token 傳給 API、必要時換發新的。它的設計哲學是短命：效期有限，到期就失效。短命不是找麻煩，是控制傷害半徑，憑證若被攔截或外洩，攻擊者能用的窗口就這麼長。服務端每次收到請求都重新查驗，你撤回授權後，下一次請求就會被擋下。

refresh token 是負責續約的憑證。Google 的文件是這樣寫的：當應用需要跨 access token 效期持續存取時，可以取得 refresh token，而是否核發、何時失效，由授權流程與政策決定；若應用取得了有效的 refresh token，access token 過期後便能拿它向授權伺服器換發新的 access token，全程不需要你重新登入。「授權一次，之後安靜運作」的祕密就在這裡：你授的是一條「refresh token 仍然有效就能自動續約」的線，不是一張一次票。

不過這條線不是永遠不斷。Google 文件明列 refresh token 停止運作的幾種情況：使用者撤回了應用的存取權、refresh token 超過六個月沒有使用、使用者變更密碼而 token 範圍包含 Gmail、帳號持有的有效 refresh token 超過數量上限、限時授權到期，以及管理員把應用要求的服務設為受限。對你的實際意義有兩層：你今天撤回授權（下一節的步驟），refresh token 跟著作廢，工具從此換不到新的 access token，存取自然停止；而就算你什麼都沒動，這條線也可能因為上述任何一種情況斷掉。所以「定期盤點授權清單」值得排進帳號衛生習慣：掛著的線要知道什麼時候該剪，斷掉的線也要知道是常態而非意外。

兩種 token 的分工可以用一個比喻記住：access token 像飯店房卡，刷了就進門，房卡有期限；refresh token 像你的會員資格，房卡過期時櫃檯憑會員資格補發新卡。房卡到期不能再用；你退掉會員（撤回授權）則像直接停用門禁，補發同時停止，還沒到期的房卡也進不了門；而會員資格本身也有失效條件，太久沒使用、改了密碼而範圍含 Gmail、超出數量上限都會讓資格作廢。所以工具能不能一直續卡，看的不是你按過同意這個動作，而是那份會員資格到現在還在不在。

同一套原則，不同類型的應用各有走法

OAuth 是框架，不是單一條路。Google 的授權文件把應用分成幾種類型：網頁伺服器應用、安裝在裝置上的應用、瀏覽器內執行的 JavaScript 應用、輸入受限的裝置（例如電視），以及服務帳號。類型不同，授權流程的細節就不同，憑證怎麼存、怎麼提交、有沒有後端可以保管祕密，答案都不一樣。以 AI 工具來說，採網頁伺服器架構的助理可走網頁伺服器流程，桌面版或手機版的助理走安裝式應用流程，兩者殊途同歸，都會把你帶到同一個瀏覽器裡的 Google 同意畫面，因為輸入密碼這件事被設計成只發生在 Google 自己的頁面。

對使用者來說，這個分類的意義在於解釋一個常見的疑惑：為什麼桌面版工具授權時會彈出一個瀏覽器視窗，授權完又跳回應用程式？在本文示意的這種安裝式應用流程裡，這是標準走法：應用程式把瀏覽器導向 Google 的頁面讓你完成登入與同意，完成後 Google 把結果導回應用註冊的重新導向 URI。看起來像繞路，實際上是刻意的：全程你的密碼只進過 Google 的頁面，應用程式只在終點領 token。理解這一點，你就能分辨正規流程與可疑流程；在這類安裝式應用上，正規的是「跳到瀏覽器、網址是 Google、跳回應用」，可疑的是「密碼直接打在應用自己的畫面裡」。

scope 權限分級：唯讀與讀寫，差的不只是一個字

同意畫面上那些「查看」「查看及編輯」的字眼，對應的術語叫 scope，授權範圍。它是整個 OAuth 裡對你最實用的概念，因為它是你能讀懂、也直接決定風險大小的那一段。Google Workspace 開發者指南對同意畫面的說明給了很清楚的定義：在 Google Workspace API 中，scope 是一段 OAuth 2.0 的 URI 字串，同時編碼了兩件事，存取哪一種資料，以及存取到什麼程度。同樣是日曆相關的範圍，「查看日曆」與「查看及編輯日曆」是兩個不同的 scope，前者只能讀，後者能改能刪。

唯讀與讀寫的差別，值得用放大鏡看。唯讀範圍下，工具最糟的情況是把你的資料看光、外流，你的原始資料還在原處。讀寫範圍下，工具可以在你的帳號裡建立、修改、刪除內容：一個要「整理行程」的助理若拿了編輯權，它誤刪一場會議或把時間改錯，後果直接落在你的真實生活裡。給權限之前先問自己：我要它做的那件事，真的需要寫入嗎？只要摘要，就不要給編輯。Google 的指南也對開發者喊話，建議只申請應用實際所需的範圍，這條最小權限原則對使用者端的啟示是：畫面上出現的範圍若明顯超過工具宣稱的功能，那就是一個該停下來的訊號。

scope 本身還有分級制度。Google 把範圍分為非機密、機密、受限三級：非機密級只碰到與特定動作直接相關的有限資料，屬於最輕的一級；機密級對應個人使用者資料、資源或動作，應用要通過額外的應用程式審查才能取得；受限級再往上加碼，對應高度敏感或存取範圍龐大的資料類別與最重的合規要求，連安全評估都要過。這套審查也有明確的豁免界線：Google 明載，僅供自己 Workspace 組織內部使用的應用，機密或受限範圍不需要另經 Google 審查。所以分級給你的參考座標是資料敏感度：同意畫面上要求的範圍落在哪一級，大致代表這個工具能碰到的資料有多敏感；至於審查把關了多少，外部應用與內部應用並不相同，不宜從範圍等級直接反推。

把使用者端看得到的權限層級整理成下表。名稱以 Google 帳號說明的分類為準，其他服務的用語可能不同，但「基本資料、唯讀、可管理」的三層結構很常見。

一個容易被忽略的角落：範圍的效力是「單向放大」的。你給了唯讀，工具做不了管理；但你在另一個服務給了讀寫，兩份授權不會互相抵銷，也不會合併計算。帳號的總暴露面，等於所有授權的聯集。這也是為什麼盤點授權要整份清單看，不能只憑印象記得「我好像只給過一個工具」。

順帶看清 scope 的兩種長相，讀文件與看畫面都會更順。對開發者，它在 Google Workspace API 中是正式的 URI 字串，每個範圍一段位址，程式碼裡逐一宣告；對使用者，同意畫面把它呈現成白話句子，例如查看、編輯、管理這類動詞配上資料類型。要對範圍做判斷，畫面句子是起點，不是終點，因為你真正授權的依據，是畫面上逐條列出的權限項目本身；看到含糊的大範圍句子時，把它當成「這包了不少」的訊號處理，回到工具的功能需求去對照合理不合理，逐條讀完再決定，比逐字解讀句子更有用。

按下「同意」之前的三個檢查

同意畫面是你手上權力最大的那一刻，按下去之前，服務理論上什麼都沒拿到；按下去之後，範圍內的資料就對工具開門。三個檢查，每個都是十秒內可以做完的事。

第一個檢查：誰要存取，用哪一個帳號。看清畫面上的應用程式名稱與開發者，問一句「這是我剛剛正在用的那個工具嗎」。網頁跳轉的流程裡，偽裝成授權頁的釣魚頁面是老招，確認網址是 Google 網域再輸入任何東西。帳號選擇是另一個坑：多數人有不只一個 Google 帳號，工作帳號的日曆與私人帳號的日曆是兩個世界，授權給錯帳號，工具讀不到行程，你還以為它壞了。授權畫面通常會讓你選帳號，選之前想一下資料在哪一邊。

第二個檢查：讀取還是修改。逐條讀權限清單，特別注意「編輯」「管理」「刪除」這幾個字。對照工具宣稱的功能：一個只說「幫你看本週行程」的助理，要求「查看及編輯所有日曆」，中間的落差就是你的談判空間，有些工具提供權限較小的選項，值得找找；找不到，就回到你信不信這個工具的判斷。

第三個檢查：資料拿去做什麼。請查看工具的隱私權政策，確認是否交代資料用途、是否用於改進模型、是否分享給第三方。這一步花的時間比前兩個多，但對 AI 工具尤其重要，因為你的資料可能被送到模型端處理。讀政策不必逐字，抓三個答案就夠：資料存哪裡、放多久、會不會變成訓練材料；查看政策是否說明處理地點與保留期間，沒有說明的，直接向工具提供者查詢。找不到答案本身就是答案。

三個檢查的共同原則，是把同意畫面當契約簽。範圍清單是對方開出的條款，你的按鍵是簽名。契約簽之前逐條讀，是常識，不是過度謹慎。

不用了就收回來：撤回授權的實際步驟

授權不是嫁出去的女兒，隨時可以收回，而且不需要改密碼。以 Google 帳號為例，Google 帳號說明寫得明白：你隨時可以查看哪些第三方應用程式和服務有權存取帳號資料，並移除存取權。實際路徑：登入 Google 帳號，由帳號說明頁的「查看應用程式和服務」進入第三方應用程式存取權的頁面，在那裡可以查看有哪些應用有權存取你的帳戶資料，並對個別應用移除存取權。查看的重點是每個應用取得哪些權限範圍，正好可以搭配上一節的三層表逐一檢視。

撤回之後發生什麼？機制上，refresh token 作廢，工具換不到新的 access token，對你資料的存取就此停止。這比「解除安裝應用程式」徹底得多，因為有些工具的存取發生在雲端，你手機上刪掉 App，它的伺服器還拿著憑證繼續讀。

但有一步是撤回做不到的，也是最多人誤解的一步：已經被複製走的資料，不會因為撤回而消失。Google 的說明直說：撤銷存取權後，應用程式無法再存取你的資料，但已取得的資料，你可能要另行要求第三方刪除。想像你授權的那幾個月裡，工具每天把你的日曆抄一份回它自己的資料庫，撤回只是停掉「繼續抄」，資料庫裡那些副本的去留，取決於對方的刪除政策與你後續的請求。要徹底清帳，撤回之外還要往工具端走一遭，找它的刪除資料管道，這在重視隱私的場景（信件、客戶資料）不是可有可無的一步。

幾個實務建議。盤點頻率抓每季一次，清單裡叫不出名字或已經不用的應用，直接移除。有些資料分享情境可以選效期，Google 說明提到部分情況下可選擇只分享一次靜態副本，或授予 30 天、180 天的期限，期限將至系統會通知，能用短期限的就別給永久。發現濫用，檢舉管道也在這說明頁上。順帶一提，你撤回授權之後，工具端通常會顯示斷線或要求重新授權，例如以 OAuth 連 Google Search Console 的工具，權限一收，資料拉不到，重新連線才會恢復，這個行為在站上的Search Console MCP 串接指南的授權步驟裡也能對上。

授權清單與帳號本身的生死也有互動，Google 說明交代得很清楚，三種情況要分開看。情況一：刪除 Google 帳號，所有相關的第三方連結會一併刪除，授權跟著源頭一起消失。情況二：刪除第三方自己的帳號，不影響你的 Google 帳號；但這句話只保證帳號本身不受影響，不代表你不必再檢查授權清單，對方已複製的資料副本也仍然要走刪除管道處理。情況三，也是真正容易漏掉的：你只是停用某個工具、換了別的服務，這時授權還掛在帳號上，需要手動收回。三種情況三種處置，不能用一句「對方消失了就沒事」帶過。

把盤點變成固定動作，可以照這個順序走一遍：

1. 打開第三方應用程式存取權頁面，把清單完整看過一次，不只看前十筆。
2. 逐筆問三個問題：這是什麼工具？我還在用嗎？它拿的權限符合我現在的用法嗎？
3. 叫不出名字的、已經不用的，直接移除存取權。
4. 還在用但權限明顯過大的（只要摘要卻拿著讀寫），移除後改用較小權限重新授權一次。
5. 敏感帳號（工作帳號、客戶資料所在帳號）再追一遍各工具的資料刪除管道，把撤回做不到的副本一併清掉。

OAuth 與 MCP 的分工：一個管連接，一個管鑰匙

談 AI 工具的授權，很難不碰到另一個名字：MCP，Model Context Protocol。它與 OAuth 的關係常被問成「是不是取代」，答案是否定的，兩者在不同層做事。MCP 解決的是「AI 應用怎麼連接外部工具與資料來源」：伺服器把能力包成工具，客戶端照協定呼叫。OAuth 解決的是「受保護的服務允許誰存取什麼」：身分怎麼確認、鑰匙怎麼發、範圍怎麼限。一個是插座與插頭的規格，一個是門禁系統的規格，房子兩套都要有。

這不是比喻，是寫進規格的。MCP 規格 2025 年 6 月 18 日版的授權章節開宗明義：MCP 在傳輸層提供授權能力，讓用戶端代表資源擁有者存取受限的 MCP 伺服器；這套機制以 OAuth 2.1 草案為基礎，支援授權的 HTTP 傳輸實作應遵循此章，MCP 伺服器扮演 OAuth 2.1 資源伺服器的角色，並強制用戶端實作 PKCE 加強授權碼的安全。換句話說，MCP 自己不發明鑰匙系統，它直接採用 OAuth 這套。你在 MCP 連線設定裡看到的「瀏覽器跳轉、登入、按同意」，就是本文前半走過的那套流程，換了舞臺，舞步相同。

規格細節上，這一章以 OAuth 2.1 等既有規格的部分功能為基礎，再訂定一整組安全要求。章節結構從角色定義開始：MCP 伺服器作為資源伺服器，接受並回應受保護資源的請求；用戶端要先找到授權伺服器的位置、取得伺服器詮釋資料，支援動態用戶端註冊的環境還能讓用戶端自動取得 client ID，省去人工預先登記；接著才是授權流程本身、access token 的使用與保管、錯誤處理，以及一整節安全考量，包括 token 的對象綁定與驗證、遭竊風險、通訊安全、授權碼保護、重新導向的防護，以及「混淆代理人」這類代理場景特有的風險。不過規格把要求寫得再細，也不代表每一個實作都安全；實際的安全水位，取決於伺服器與用戶端有沒有照要求實作，這在挑選 MCP 工具時仍是你要睜大眼睛的部分。

規格裡還有一個對判斷有用的細節：授權對 MCP 實作是選配，而且不同傳輸方式待遇不同。需要授權、且採用這一章機制的 HTTP MCP 連線，才會走瀏覽器的 OAuth 授權流程；走 STDIO（本機行程間通訊）的實作則不建議套用這套網頁流程，而是從執行環境取得憑證。還要把分層看清楚：MCP 連線本身的授權，與 MCP 伺服器向上游 API（例如 Google 日曆）取得的授權，是兩份不同的憑證、兩道不同的關，規格也明文禁止把前者直接轉手給後者。對使用者的啟示是：授權畫面出現與否，取決於連線形態與實作選擇，本機直連的連線可能從環境變數取得金鑰，不出現登入頁也屬正常；兩種都是規格允許的做法，不必因為「沒跳登入畫面」就覺得不安全，也不必因為「跳了登入畫面」就假設它經過某種官方認證。

把鏡頭再拉遠一點，AI 工具的連線世界還有幾塊拼圖：MCP 之外，網頁這一側有 WebMCP，代理之間的識別與描述有 Agent Card。這兩套規格的機制細節與授權設計，超出本文六份一手文件查證的範圍，這裡不替它們下斷言，但沿著本文的思路去看它們，問的仍是同一組問題：連線怎麼建立、憑證怎麼發、範圍怎麼限。想深入這條軸線，站上的MCP 運作原理專文拆了 Host、Client、Server 的架構與成本，WebMCP 導入指南與Agent Card 解析則分頭深入這兩個規格，三篇與本文正好拼成 AI 工具連線世界的四個切面。

三個常見誤解，拆掉之後判斷會變簡單

誤解一：授權等於把帳號交出去。事實相反，OAuth 的整個設計就是為了讓你不必交出帳號。走本文示範的這種瀏覽器導向流程，工具拿不到你的密碼，拿到的是範圍有限、效期有限、可單獨撤回的憑證。真正的風險與「帳號被拿走」無關，落在「你同意的範圍有多大、對方拿到資料之後怎麼用」。把注意力從前者移到後者，檢查才會做在刀口上。

誤解二：撤回授權，資料就清乾淨了。前面講過，撤回停掉的是未來的存取，過去被複製的資料還在對方手裡。這個誤解的代價是安全感錯置：你可能撤回了授權就以為結案，忘了追對方的刪除管道。正確的心智模型是把授權想成兩段式，門禁卡先停（撤回授權），倉庫裡的舊貨再清（要求刪除資料）。

誤解三：通過了 OAuth 流程，等於 Google 背書這個應用。同意畫面的存在代表這個應用接上了 Google 的授權系統，機密範圍要求額外審查，受限範圍還要求安全評估（僅供組織內部使用的應用另有豁免），但它不是品格保證書。一個通過審查的應用仍可能在隱私政策裡寫了你不喜歡的用途，仍可能把資料用在你不預期的地方。審查機制過濾的是規格面的風險，用途面的判斷始終在你手上，這正是「第三個檢查」存在的理由。

收在一個可操作的結論上。OAuth 把「要不要信任一個工具」拆成了一連串可以個別回答的小問題：它要什麼範圍、唯讀還是讀寫、效期多久、隨時可收回、收不回的副本有多少。你不需要懂協定細節也能把這些問題答好，只需要在按同意之前多花三十秒逐條讀畫面，在季度盤點時把清單叫出來砍一遍。帳號的安全從來不是不出事的神話，而是把每一把發出去的鑰匙都留在自己看得見的清單上，這件事 OAuth 已經把工具做齊了，剩下的紀律是使用者的。