什麼是 OAuth？「使用 Google 登入」與委派存取白話解說

OAuth 是一項開放標準，讓使用者能夠在不交出密碼的情況下，給予某個應用程式在另一項服務上有限的帳號存取權限。當你點擊「連結 Google 行事曆」，然後看到一個詢問「允許此應用程式查看你的活動嗎？」的畫面時，就是 OAuth 在運作。應用程式取得的權杖只涵蓋你核准的範圍，而且你隨時可以撤銷。同樣的機制，再加上一層稱為 OpenID Connect 的協定，就是「使用 Google 登入」及類似按鈕背後的技術。

用 AI 製作 App 時為什麼 OAuth 很重要

製作 App 時，OAuth 通常會在兩種情況下出現：

1. 社群登入。 你希望使用者可以用「使用 Google 登入」（或 Apple、Microsoft、GitHub）來代替另外建立一組密碼。請參閱如何為你的 App 加入登入功能。
2. 連接使用者在其他服務上的帳號。 你的 App 需要讀取使用者的行事曆、代替他們發文到社群帳號、從雲端硬碟抓取檔案，或同步他們的會計資料。

在這兩種情況下，AI 製作工具都能寫出程式碼，但有些步驟只有你本人能做：在服務提供者那裡建立開發者應用程式、取得客戶端 ID 與客戶端密鑰、登記回呼網址，以及對於某些權限，還需要通過提供者的審核。了解 OAuth 的運作方式，會讓這些步驟及它們產生的錯誤不再那麼神秘。若想了解登入的整體概念，請參閱什麼是驗證。

日常比喻

想像一張飯店的房卡。辦理入住時，櫃檯會確認你的身分，然後給你一張房卡，可以開你的房間與健身房，但不能開其他房間或員工區域，而且退房後就失效。房卡上不包含你的護照資料。如果遺失了，櫃檯會註銷它並發出新卡。

• 櫃檯就是授權伺服器（Google 的登入頁面）。
• 你的身分查驗就是你在 Google 登入。
• 房卡就是存取權杖。
• **「只限房間與健身房」**就是你核准的權限範圍（scope）。
• 退房就是權杖過期，或你撤銷存取權限。

你正在使用的 App 從來不會看到你的 Google 密碼，只看到那張房卡。

OAuth 運作流程，一步一步來

Web 應用程式最常見的流程是授權碼流程（authorization code flow）。以下是使用者把 Google 行事曆連接到一個排程 App 時發生的事情：

1. 點擊。 使用者點擊「連結 Google 行事曆」。
2. 重新導向到提供者。 App 把瀏覽器導向 Google，並附上它的客戶端 ID、想要的權限範圍（讀取行事曆活動），以及 Google 完成後應該把使用者送回的重新導向 URI。
3. 登入並同意。 使用者登入 Google（如果尚未登入），並看到一個列出 App 所要求權限的同意畫面。使用者按下允許。
4. 帶著代碼回來。 Google 把瀏覽器重新導向到 App 的重新導向 URI，並附上一個短效、只能使用一次的授權碼。
5. 在伺服器上交換。 App 的伺服器把該授權碼與它的客戶端密鑰直接送給 Google，並收到一個存取權杖（通常也會收到一個重新整理權杖）。
6. 使用 API。 伺服器帶著存取權杖呼叫 Google 行事曆 API，取得使用者的活動。

第 4 步中的回呼大致會像這樣：

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

而第 5 步中的權杖回應是 JSON 格式，像這樣：

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

重要的設計重點是：權杖的交換發生在伺服器之間，因此客戶端密鑰與權杖永遠不需要經過瀏覽器。

OAuth vs OpenID Connect vs 你自己的登入

許多應用程式會結合這些方式：電子郵件加密碼登入，加上透過 OIDC 的「使用 Google 登入」，再加上與其他服務分開的 OAuth 連接。

關鍵術語

常見迷思

• 「OAuth 是登入系統。」 單純的 OAuth 只負責授予存取權限；身分驗證由 OpenID Connect 處理。把單獨的存取權杖當成某人身分的證明，已經造成過真實的安全漏洞。
• 「應用程式會拿到我的密碼。」 它永遠不會。這正是設計的重點。
• 「多要求一些權限範圍沒有關係。」 使用者對過於寬泛的要求會更加謹慎，而 Google 等提供者對敏感或受限的權限範圍可能要求應用程式審核。只要求你需要的權限。
• 「客戶端密鑰可以放在前端。」 任何放在瀏覽器程式碼中的東西都是公開的。請把它保存在伺服器端的機密中。
• 「測試時能運作，正式上線就會運作。」 提供者通常會限制未經驗證的應用程式，例如只允許列出的測試使用者，而正式網域的重新導向 URI 必須另外登記。
• 「權杖會永遠有效。」 存取權杖很快就會過期，使用者也可以撤銷存取權限。你的應用程式必須優雅地處理這兩種情況。

可以向 AI 製作工具提出的要求

• 「使用 OpenID Connect 加入「使用 Google 登入」，並採用維護良好的驗證函式庫，不要自己手刻 OAuth 流程。」
• 「使用搭配 PKCE 的授權碼流程，並檢查 state 參數。」
• 「從伺服器端的環境變數讀取客戶端 ID 與客戶端密鑰。」
• 「只要求我們需要的權限範圍：唯讀的行事曆存取。」
• 「告訴我需要在提供者的主控台中登記哪些重新導向網址，包括預覽、已發佈網址與我的自訂網域。」
• 「把重新整理權杖加密後存進資料庫，並在權杖過期或被撤銷時，請使用者重新連接。」
• 「讓使用者能在設定頁面中中斷與此整合的連線。」

OAuth 與 Mythex

Mythex 沒有為你製作的 App 內建終端使用者登入功能；它的文件描述的是「自備方案」的做法：你選擇一個驗證函式庫或託管的提供者，把它的金鑰存為專案機密，再由 Agent 撰寫程式碼。新增驗證食譜中附有可以直接使用的起始提示詞。你也會在 Mythex 本身遇到 OAuth：你可以用 Google 註冊，連接 GitHub 來同步儲存庫時會使用 GitHub 的 OAuth，而透過 MCP 連線到 Mythex 的 AI 用戶端，則會經過一個 OAuth 同意頁面。更多資訊請參閱什麼是驗證與什麼是雙因素驗證。

常見問題