OAuth 中文詳解：授權原理、流程步驟與香港企業實際應用

OAuth（Open Authorization）是現代互聯網最重要的授權協議之一，幾乎每個人每天都在使用它，卻往往不知道它的名字。每當你點擊「以 Google 帳號登入」、授權某個應用程式存取你的 Facebook 專頁，或者連接網店平台與第三方系統，背後都有 OAuth 在運作。

本文以淺白中文解釋 OAuth 是什麼、OAuth 2.0 的四個核心角色、授權碼模式的完整流程、Access Token 與 Refresh Token 的分別，以及 OAuth 與 OIDC、SAML 的關係——特別適合需要理解技術原理、但不需要自行寫程式碼的香港產品經理、業務負責人及市場營銷人員閱讀。

OAuth 是什麼？用一個例子說清楚

想像你要用一間網上沖印服務，把存放在 Google Photos 的照片印出來。傳統方法是：把自己的 Google 帳號和密碼直接交給沖印公司，讓他們登入你的帳號下載照片。這做法危險得令人不安——因為你等於把整個 Google 帳號的控制權拱手相讓。

OAuth 解決的正是這個問題。有了 OAuth，你只需要告訴 Google：「讓這間沖印公司在接下來 30 天內，存取我的 Photos 相冊」——沖印公司從頭到尾都看不到你的密碼，只收到一個有時效、有範圍限制的「授權憑證」。

OAuth（Open Authorization）的定義很清晰： 它是一個開放標準協議，讓用戶可以授予第三方應用程式存取自己在另一個服務上的特定資料，而無需分享密碼。用戶可以精確控制開放哪些權限，並隨時撤銷授權。

OAuth 最初於 2006 年提出，OAuth 2.0 版本於 2012 年正式發布，現時最佳實踐標準（2026 年）是 OAuth 2.0 配合 PKCE 擴展（下文詳述）。

OAuth 和「登入」的分別：授權 ≠ 身份驗證

很多人誤以為 OAuth 等同於「第三方登入」，但這是一個常見的混淆。OAuth 2.0 處理的是「授權（Authorization）」，而非「身份驗證（Authentication）」：

OAuth 只告訴資源伺服器「這個應用程式有權存取這位用戶的資料」，但它並不會告訴應用程式「這個用戶是 John Smith，電郵是 john@example.com」。要取得身份資訊，需要在 OAuth 之上加入 OIDC（OpenID Connect）。

什麼時候用 OAuth？什麼時候用 OAuth + OIDC？

純 OAuth（不需要身份資訊）的場景：

• API 整合：讓 SleekFlow 存取你的 Facebook 專頁訊息

• 第三方平台授權：允許某個應用程式讀取你的 Google Calendar、Shopify 訂單資料

• 後台系統對接：一個伺服器存取另一個伺服器的 API

OAuth + OIDC（同時需要身份資訊）的場景：

• 「以 Google 帳號登入」：你希望知道用戶是誰，以便在自己的系統建立帳號

• 「以 Facebook 帳號登入」：取得用戶的姓名和電郵，省去他們手動填寫表單

技術提示（開發者適讀）：在 OAuth 授權請求中加入 scope=openid，即可啟動 OIDC 擴展。授權伺服器除了返回 Access Token，還會額外返回一個包含用戶身份聲明的 ID Token。

OAuth 2.0 的四個核心角色

理解 OAuth 的運作，必須先認識四個核心角色。以 SleekFlow 連接 Facebook 專頁為例，四個角色分別對應如下：

角色一：Resource Owner（資源擁有者）

Resource Owner 是擁有被請求資料的用戶——在商業場景中，通常是坐在鍵盤前、擁有 Facebook 專頁或 Google 帳號的業務負責人。

資源擁有者掌握授權的最終控制權：他們查看授權同意介面、決定開放哪些權限，並可以隨時從平台設定頁面撤銷授權（例如從 Facebook「設定」→「應用程式和網站」，可以看到所有已授權的第三方應用程式並一鍵移除）。

特殊情況補充：在機器對機器（Machine-to-Machine）的整合中，沒有人類用戶參與，Resource Owner 的概念會有所改變——詳見下文 Client Credentials 流程部分。

角色二：Client（客戶端應用程式）

Client 是請求存取資料的應用程式——即向資源擁有者申請授權的一方。

• 在用戶連接 Facebook 專頁時，SleekFlow 是 Client

• 在用戶「以 Google 帳號登入」某個網站時，該網站是 Client

開發者提示（Client ID 與 Client Secret）：開發者在向授權伺服器（如 Meta 開發者平台）註冊應用程式後，會取得一個 Client ID（應用程式的公開識別碼）和一個 Client Secret（私密金鑰，用於向授權伺服器證明應用程式的身份）。Client Secret 只能保存在伺服器端，絕不能暴露在用戶的瀏覽器中。

角色三：Authorization Server（授權伺服器）

Authorization Server 負責三件核心事項：

• 驗證資源擁有者的身份（確認他們是帳號的合法擁有者）

• 展示授權同意介面（列出應用程式請求的具體權限）

• 在用戶批准後發放憑證（Access Token 和 Refresh Token）

常見的授權伺服器包括：Meta（管理 Facebook、Instagram、WhatsApp 的授權）、Google（管理 Gmail、Google Drive、Google Calendar 的授權）、GitHub（管理代碼庫存取）以及 Shopify（管理網店資料存取）。

重要區分：授權伺服器和資源伺服器可以屬於同一間公司，但功能截然不同——授權伺服器發放「許可」，資源伺服器儲存「數據」。

角色四：Resource Server（資源伺服器）

Resource Server 是持有受保護數據的 API 伺服器。 它接受 Access Token 作為授權憑證，驗證其有效性、有效期及權限範圍後，才返回被請求的數據。

• SleekFlow 想讀取某 Facebook 專頁的訊息：SleekFlow（Client）向 Meta Graph API（Resource Server）發送請求，附帶 Access Token；Meta 驗證 Token 有效且包含 pages_messaging 權限後，才返回訊息內容。

關鍵點：一旦初始授權完成，資源擁有者無需在場——每次 API 呼叫都由 Access Token 自動處理授權，業務負責人不需要每次重新批准。

OAuth 2.0 授權流程詳解

最常用的授權流程：授權碼模式（Authorization Code Flow）

授權碼模式是 Web 應用程式最常用的 OAuth 2.0 流程，以下以 SleekFlow 連接 Facebook 為例，逐步拆解：

Step 1｜用戶發起授權請求 管理員在 SleekFlow 後台點擊「連接 Facebook 專頁」。SleekFlow 將管理員跳轉至 Meta 的授權伺服器，請求中帶有：

• client_id：SleekFlow 在 Meta 平台的應用程式 ID

• redirect_uri：授權完成後返回 SleekFlow 的地址

• scope：請求的具體權限（如 pages_messaging、pages_read_engagement）

• state：隨機字串，用於防止 CSRF 攻擊

Step 2｜用戶登入並確認授權 管理員在 Meta 頁面完成 Facebook 登入（若尚未登入），然後看到授權同意介面，列出 SleekFlow 具體請求什麼權限。管理員點擊「確認」。

Step 3｜授權碼返回 Meta 將管理員跳轉回 SleekFlow 的 redirect_uri，同時附帶一個短效、一次性使用的「授權碼（Authorization Code）」。

Step 4｜後端用授權碼換取 Token SleekFlow 的伺服器將授權碼連同 Client Secret，發送至 Meta 的 Token 端點。此步驟完全在伺服器之間進行，管理員的瀏覽器看不到 Client Secret。Meta 驗證無誤後，返回 Access Token 和 Refresh Token。

Step 5｜使用 Access Token 存取資源 SleekFlow 使用 Access Token 呼叫 Meta Graph API，取得專頁訊息、訂閱 Webhook，讓入站訊息實時流入 SleekFlow 的收件箱。整個過程，管理員的 Facebook 密碼從未離開 Meta 的系統。

為什麼需要「授權碼」這個中間步驟？

若省略授權碼，Authorization Server 將直接把 Access Token 放在 URL 中返回至瀏覽器（前端通道）。 瀏覽器中的 Token 極易通過瀏覽器歷史記錄、Referrer 標頭或惡意瀏覽器擴展洩露。

授權碼本身沒有直接用途——即使被截獲，也無法單獨換取 Token，因為換取過程需要 Client Secret。Client Secret 只存在於 SleekFlow 的伺服器（後端通道），從不暴露給瀏覽器。這個設計讓授權碼模式比直接返回 Token 安全得多。

2026 年推薦：授權碼 + PKCE 模式

什麼是 PKCE？為什麼它在 2026 年如此重要？

PKCE（Proof Key for Code Exchange，讀音 "pixie"）是授權碼流程的安全擴展，專門防止授權碼被截獲後遭惡意使用——尤其在無法安全保存 Client Secret 的環境中（如手機應用程式、單頁應用程式 SPA）。

PKCE 的工作原理（在授權碼流程之上）：

1. 授權請求發出前，客戶端生成一個隨機字串 code_verifier

2. 對 code_verifier 進行雜湊運算，得到 code_challenge

3. code_challenge 隨授權請求一同發送至授權伺服器

4. 用授權碼換取 Token 時，同時發送原始的 code_verifier

5. 授權伺服器驗證：hash(code_verifier) = code_challenge——確認完成請求的是同一個客戶端

哪些流程已過時或不應再使用？

⚠️ Implicit Flow（隱式授權模式）— 已棄用，切勿使用 Implicit Flow 是 OAuth 2.0 早期為 SPA 設計的流程，將 Access Token 直接放在 URL 碎片（fragment）中返回，省去授權碼的中間步驟。問題在於 URL 中的 Token 極易被竊取，已在 OAuth 2.1 草案及 RFC 9700（OAuth 2.0 安全最佳實踐） 中正式棄用。現有系統若仍使用 Implicit Flow，應儘快遷移至授權碼 + PKCE 模式。

⚠️ Resource Owner Password Credentials（ROPC）— 已棄用 ROPC 允許客戶端直接收集用戶的帳號和密碼，再用這些憑證換取 Token——這完全違背了 OAuth「不分享密碼」的核心設計原則，已被棄用。唯一有限度合理的用途，是高度受信任的自家應用程式在從舊版認證系統遷移期間的過渡方案。

其他授權流程

Client Credentials（機器對機器，無用戶）

Client Credentials 流程適用於沒有人類用戶參與的場景——一個伺服器或應用程式需要以自身身份存取另一個伺服器的 API。

• 流程：客戶端直接向授權伺服器發送 Client ID + Client Secret，取得 Access Token；全程無用戶同意介面

• 典型場景：SleekFlow 後台伺服器定期向 Meta API 查詢所有已連接帳號的訊息發送狀態——這是一個無需特定用戶授權的後台批次作業

Refresh Token（令牌更新機制）

Access Token 設計上是短效的（通常 1 小時至 24 小時），以限制 Token 一旦洩露後的損害範圍。但若每次 Token 過期都要求用戶重新授權，用戶體驗會極差。

Refresh Token 解決了這個問題：

• 初始授權時，Access Token 和 Refresh Token 同時發放

• Access Token 過期後，客戶端靜默地將 Refresh Token 發送至授權伺服器，換取新的 Access Token，用戶完全無感知

• 安全注意事項：Refresh Token 是長效憑證（有時長達數月或數年），必須安全儲存於伺服器端；絕對不能放在瀏覽器的 localStorage 或 sessionStorage（容易受 XSS 攻擊），應使用伺服器端會話儲存或加密的 HttpOnly Cookie。

Access Token 和 Refresh Token 包含什麼資訊？

現代 Access Token 通常是 JWT（JSON Web Token，讀音 "jot"） 格式——一個自包含、已數位簽署的字串，格式為：

[標頭（Header）].[有效載荷（Payload）].[簽名（Signature）]

三個部分均以 Base64 編碼，可以被解碼讀取（但無法在不知道私鑰的情況下偽造）。

Payload 通常包含：

資源伺服器使用授權伺服器的公鑰驗證 JWT 的數位簽名，確認 Token 確實由合法的授權伺服器發放且未被篡改——整個過程無需查詢資料庫，大幅提升 API 回應速度。

Access Token 的有效期及安全注意事項

典型有效期：

• 短效（1 小時）：最安全，是大多數授權伺服器的預設值

• 長效（24 小時）：用戶體驗更好，但 Token 一旦洩露，風險窗口更長

Token 儲存最佳實踐：

• ❌ 不應儲存於 localStorage 或 sessionStorage（易受 XSS 攻擊）

• ❌ 不應儲存於未設定安全標誌的 Cookie

• ✅ 應儲存於伺服器端會話，或設有 HttpOnly 和 Secure 標誌的 Cookie

Refresh Token 的管理

授權伺服器可以為 Refresh Token 設定不同的到期策略：

• 滑動過期：每次使用 Refresh Token 換取新 Access Token 時，Refresh Token 的有效期順延

• 絕對過期：無論使用頻率，Refresh Token 在固定時間後到期

• 一次性使用：每次換取新 Access Token 時，舊 Refresh Token 立即失效，同時發放新的 Refresh Token

Token 撤銷：如何終止授權

資源擁有者可隨時撤銷 OAuth 授權：

• 在 Facebook，前往「設定」→「安全和登入」→「應用程式和網站」→ 選擇應用程式 → 點擊「移除」

• 撤銷後，Access Token 和 Refresh Token 立即失效；後續使用該 Token 的 API 請求將返回 401 Unauthorized 錯誤

從 SleekFlow 側斷開連接：在 SleekFlow 的「渠道整合」設定中移除已連接的 Facebook 或 Instagram 渠道，SleekFlow 將撤銷本地儲存的 Token 並終止訂閱。業務負責人亦建議同時在 Facebook 平台設定中確認移除，確保授權完全終止。

OAuth 在實際業務中有何應用？

以 SleekFlow 連接 Facebook 專頁為例

當 SleekFlow 管理員點擊「連接 Facebook 專頁」時，以下事情依次發生：

1. SleekFlow 生成授權 URL，包含 client_id、redirect_uri（返回 SleekFlow 的地址）、scope（pages_messaging、pages_read_engagement、pages_manage_metadata）及 state 參數

2. 管理員被跳轉至 Facebook 登入頁面，完成登入後看到授權同意介面，列出 SleekFlow 請求存取的具體權限

3. 管理員點擊「以 [姓名] 身份繼續」，確認連接哪些 Facebook 專頁

4. Facebook 跳轉回 SleekFlow，附帶 Authorization Code

5. SleekFlow 的伺服器 用 Authorization Code + Client Secret 向 Meta 換取 Access Token

6. SleekFlow 安全儲存 Access Token（於伺服器端），並用它訂閱專頁的 Webhook，使入站訊息實時到達 SleekFlow 收件箱

7. 此後，Facebook 訊息自動出現在 SleekFlow 的統一收件箱——管理員的 Facebook 密碼，從頭到尾都沒有傳送給 SleekFlow

如需了解 SleekFlow 如何整合 Facebook 專頁 或 Instagram 帳號，可查看對應的渠道整合說明。如需了解 SleekFlow 的數據安全政策，請參閱 數據安全說明頁面。

什麼是「Scope」（權限範圍）？

Scope 是 OAuth 請求中最重要的透明度機制之一——它明確定義客戶端請求哪些類型的存取。以 Meta 的 API 為例：

授權同意介面 會以平易近人的語言列出每個 Scope 的含義，確保用戶在點擊「允許」前清楚知道自己授予了什麼。這是 OAuth 透明度設計的核心體現。

最小權限原則：應用程式應只請求完成其功能所需的最少 Scope。請求過於寬泛的權限（如在只需要讀取專頁訊息時，額外要求在用戶個人時間線發文），是不良的安全實踐，且可能降低用戶的授權意願。

「以 Google 帳號登入」背後的 OAuth + OIDC

授權碼流程在「第三方登入」中的運作

當一個網站提供「以 Google 帳號繼續」時，真正發生的是：

1. 網站使用 OAuth 2.0，並在 scope 中加入 openid（啟動 OIDC 擴展）

2. 用戶同意後，Google 返回一個包含用戶姓名、電郵、頭像的 ID Token（JWT 格式），以及一個 Access Token

3. 網站使用 ID Token 在自己的系統中建立或匹配用戶帳號

4. 用戶的 Google 密碼，從未傳輸至該網站

這正是「以 Google 帳號登入」比在每個網站分別建立密碼更安全的根本原因：身份驗證由 Google 的安全基礎設施處理，網站只收到 ID Token，而非密碼。

OAuth vs 其他相關技術

OAuth vs SAML：各自適用場景

SAML 的定位及使用場景

SAML（Security Assertion Markup Language）是一個 XML 格式的企業級認證和授權標準，主要用於企業內部的單一登入（SSO）環境。當員工登入公司電腦後，無需再次輸入密碼就能存取 Salesforce、Google Workspace 和其他企業系統，背後通常就是 SAML。

SAML 的特點：

• 基於 XML：設計複雜，實施成本高

• 瀏覽器導向：依賴 HTTP 重定向，對移動設備不友好

• 企業 SSO 的主場：常見於與 Active Directory、Azure AD、Okta 等企業身份系統的整合

選擇 OAuth 還是 SAML？

2026 年的選擇原則：

現代身份提供者（如 Okta、Azure AD、Google Workspace）普遍同時支援 SAML 和 OIDC。在兩者皆可選擇的情況下，OIDC 通常因其簡潔性和更好的移動端支援而被優先選用。

OAuth vs API Key

API Key 的局限性

API Key 是另一種常見的 API 身份認證方式——客戶端在每個 API 請求中附帶一個靜態的密鑰字串，以證明自己的身份。它比 OAuth 更簡單實施，但在靈活性和安全性上存在明顯限制：

何時使用 API Key 而非 OAuth：

• 伺服器對伺服器的整合，且用戶身份並不重要

• 內部工具在受控環境中使用

• 簡單性需求明顯大於安全顆粒度需求的情況

用 SleekFlow 管理所有已授權渠道

理解 OAuth 的運作原理，有助於業務負責人更放心地連接和管理第三方平台。SleekFlow 作為支援 WhatsApp Business API、Facebook、Instagram 及 Shopify 的全渠道客戶互動平台，所有渠道連接均採用 OAuth 2.0 授權碼流程——你的帳號密碼從不接觸 SleekFlow 的系統，存取權限可隨時從各平台設定頁面撤銷。

連接完成後，SleekFlow 的 Flow Builder 自動化流程 可根據跨渠道的客戶訊息自動觸發回覆、分配對話、記錄至 CRM 系統；AI 客服 功能可 24/7 即時處理常見查詢；Webhook 整合則可將對話數據同步至外部系統。

如需了解 SleekFlow 如何協助你的業務整合各大渠道，立即預約示範，由我們的顧問為你制訂最適合的方案。

常見問題（FAQ）

本文所有技術規格以 2026 年 IETF RFC 文件及各平台官方開發者文件為準。

主要參考來源：

• RFC 6749 — The OAuth 2.0 Authorization Framework

• RFC 7636 — Proof Key for Code Exchange (PKCE)

• RFC 9700 — OAuth 2.0 Security Best Current Practice

• RFC 7519 — JSON Web Token (JWT)

• Meta for Developers — Graph API Access Tokens

• OpenID Connect Core 1.0

• IETF OAuth 2.1 Draft

• Google Identity Platform — OAuth 2.0

• Microsoft Security — What is OAuth

• Auth0 — An Introduction to OAuth 2