OAuth

OAuth 是什麼，跟直接把帳號密碼給第三方應用程式有什麼不同？

OAuth 是一套授權協定，讓使用者可以授權一個第三方應用程式（例如一個 MCP 連接器）代表自己去存取某個服務的資料或功能，而不需要把帳號密碼直接交給這個第三方。整個流程的核心是「令牌」（token）：使用者透過原本信任的身分系統（例如登入自己的 Google 帳號）完成驗證後，系統核發一張範圍受限的令牌給第三方應用程式，這張令牌只能用來做被授權的那些事，不是帳號的完整存取權。

跟直接給密碼最大的不同在於「範圍」與「可撤銷性」。密碼一旦外流，等於整個帳號的控制權都被拿走；OAuth 令牌則可以限定只能讀取特定資料、只能在特定期間內有效，而且使用者可以隨時到身分系統裡把這張令牌撤銷，不需要因此更改密碼，也不影響帳號本身的安全。

OAuth 為什麼被需要，解決了什麼問題？

在沒有 OAuth 這類機制之前，如果一個第三方應用程式需要存取使用者在另一個服務裡的資料，唯一的做法就是要求使用者把帳號密碼直接輸入給這個第三方保存。這帶來兩個具體風險：一是這個第三方一旦被入侵，外洩的就是使用者原始密碼，攻擊者能用這組密碼在原本的服務裡做任何事，範圍完全不受限；二是使用者沒有精細的控制權，只能選擇「全部授權」或「完全不用」，沒辦法只開放讀取、不開放寫入這種細緻的範圍限制。

OAuth 把授權這件事從「交出密碼」改成「核發一張範圍受限的令牌」，解決的正是這兩個問題：即使拿到令牌的第三方應用程式被入侵，外洩的也只是這張令牌，攻擊者能做的事被限定在授權範圍內，而且使用者或服務端可以隨時撤銷這張令牌，不影響原本的帳號密碼；同時使用者在授權當下可以看到具體要開放哪些權限，做出更精細的判斷，而不是全有全無的選擇。

OAuth 實際上怎麼運作，一次典型的授權流程長什麼樣子？

以 Claude 連接一個 MCP 伺服器為例，典型流程大致是這樣：Claude 先嘗試呼叫這個伺服器，如果對方要求授權，會回傳一個「未授權」的回應，裡面帶著授權伺服器的位置資訊；Claude 接著去查詢這個授權伺服器公開的中繼資料，了解它支援哪些授權方式；由於 Claude 事先不一定知道這個伺服器的身分，會先透過「動態客戶端註冊」向對方登記自己的身分，取得一組識別碼；接著才是使用者實際授權的環節——瀏覽器會開啟一個畫面，使用者登入自己在這個服務的帳號並確認要開放哪些權限；使用者確認後，服務端會核發一組憑證讓 Claude 換取正式的存取令牌，之後每次呼叫這個伺服器，都帶著這張令牌證明自己有權限。

這個過程裡有一個常見的安全機制叫 PKCE（Proof Key for Code Exchange），用來防止授權過程中的憑證在傳遞途中被攔截後被冒用；另外，令牌通常有使用期限，且會定期輪替更新，避免一張令牌被長期使用而增加外洩後的風險視窗。

OAuth 對我有什麼實際影響，作為使用者或開發者分別該注意什麼？

如果你是一般使用者，在為 Claude 連接第三方服務（例如透過連接器接上 Gmail、Slack）時看到跳出的授權畫面，這代表你正在經歷 OAuth 流程——這個畫面上列出的權限範圍值得實際看一遍，確認要開放的權限跟這個連接器實際功能是否相符，而不是看到授權畫面就直接點確認；同時記得你隨時可以到對應服務的帳號設定裡，查看目前授權了哪些第三方應用程式，並撤銷不再需要或看起來可疑的授權。

如果你是要開發一個給 Claude 使用的 MCP 伺服器，OAuth 是目前正式環境的標準要求：如果你的伺服器只支援固定的 API 金鑰驗證，使用者在 claude.ai 網頁版的自訂連接器介面（跟 Claude Code 不同，只接受 OAuth）就沒辦法直接串接。搭建 OAuth 授權需要處理不少細節（例如授權中繼資料的正確格式、PKCE 的實作、令牌輪替機制），如果不想從零開始自建，市面上已有一些現成的中介層方案可以參考，但選用前仍值得理解這套機制實際在保護什麼、以及自己的伺服器目前是否符合這套標準。