接下來，我們要再深入了解OAuth，我相信大家都會有以下的問題：為什麼需要 OAuth？它解決什麼問題？誰參與其中？今天我們先搭建全局觀念的「地圖」，接下來幾天再逐步深入。

為什麼不用「帳號密碼共享」？

在早期的網路應用中，如果一個第三方應用想幫你操作 Google 或 Facebook 的資源，通常需要你直接把帳號密碼交給它。這樣做有幾個嚴重問題：

1. 完全暴露密碼：第三方知道你的密碼，就可以任意存取所有資料。
2. 無法細分權限：你可能只想讓它讀取聯絡人，結果它卻能讀取郵件。
3. 無法撤銷：一旦你想中止，只能改密碼，導致所有使用這個帳號的服務都要重新設定。

OAuth 解決的核心就是：讓使用者不用交出密碼，也能授權第三方有限度地存取資源。

四個角色（誰在參與這場遊戲）

OAuth 世界裡有四個角色：

一張圖可以幫助理解：

• 使用者（Resource Owner）→ 點選授權
• Authorization Server → 發給 Client 一張「票」
• Client 拿票去 Resource Server → 取得資源

關鍵名詞速通

OAuth 有幾個常見名詞，你會反覆遇到：

• Access Token：存取 API 的門票。可能是字串或 JWT。
• Refresh Token：用來換取新的 Access Token（通常壽命較長）。
• Scope：授權範圍，例如 calendar.read、email。
• Consent Screen：使用者授權畫面，會顯示這個應用要什麼權限。
• Redirect URI：授權完成後要回跳的網址。必須完全相符，避免安全漏洞。
• Client Type：
  • Confidential Client：可以安全保存密鑰（如後端服務）。
  • Public Client：不能安全保存密鑰（如手機 App、前端 SPA）。

OAuth 安全思維

OAuth 提供了一些安全機制，避免流程被攻擊：

• state：防止 CSRF（跨站請求偽造）。
• PKCE（Proof Key for Code Exchange）：特別為 Public Client 設計，避免授權碼被攔截後直接冒用。
• Redirect URI 驗證：必須完全相符，避免攻擊者設置惡意回跳地址。

小劇場案例

假設你開發了一個應用 MangaCloud，希望讓使用者可以用 Google 登入，並授權讀取他們的 Email：

• 角色：你（Client）、使用者（Resource Owner）、Google（Authorization Server + Resource Server）。
• Scope：openid email profile。
• 使用者在 Consent Screen 上點擊「允許」，你的 App 拿到 Access Token → 可以讀 Email。

小結

• OAuth 解決了「不用交出帳號密碼也能授權」的問題。
• 四個角色：使用者、Client、Authorization Server、Resource Server。
• 關鍵名詞：Access Token、Refresh Token、Scope、Redirect URI、PKCE。

昨天教了一些關鍵字詞，今天則是教大家整理這些關鍵字，變成重要的四個觀念，以及OAuth所要達成的目標。那我們明天見囉！