理解 OAuth 的本質：從歷史脈絡到核心精神的深度筆記

本篇文章更新時間：2026/02/22
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。

OAuth 的真正核心是什麼？從歷史脈絡看懂一個被誤解的標準

編輯前言：市面上講 OAuth 的文章很多，但多半在講流程與技術細節，卻很少解釋「為什麼它會長成這樣」。原文《What is OAuth?》從創始者視角回到問題起點，讓我真正理解 OAuth 的設計哲學與歷史推力。

核心觀點 (Key Takeaways)

• OAuth 的核心其實非常簡單：安全地把一個「可重複使用的秘密」交給受信任的第三方，並讓它能代表使用者執行後續操作。
• OpenID Connect（OIDC）本質上就像「魔法連結登入」：把只有本人能取到的秘密寄到某個地方，然後用展示這個秘密來證明身份。
• OAuth 的複雜度來自共識、名詞、UX、安全性要求與標準化過程，而不是概念本身。

深入解析

原文作者回顧了 2006 年在 Twitter 的經驗：團隊希望支援當時的 OpenID 1.0，但遇到一個致命問題——如果使用者不用密碼登入 Twitter，那使用者要怎麼讓桌面端與其他第三方客戶端登入？這個問題其實是 Web 2.0 時代所有網站的痛點。

當時的網路世界到處是「土法煉鋼」：

• Flickr 有自己的方法
• AWS 也有自己的方法
• 有些網站乾脆讓外部應用要求使用者直接輸入原始帳號密碼

這些方法都不安全、沒有共識、也無法互通。於是 OAuth 的基礎概念誕生了。

作者用一句非常直白的描述，直接點破了 OAuth 的核心：

「OAuth 的前半段，是把使用者同意授權後的一組多次使用的秘密安全地傳給受託者；後半段則規範受託者如何使用這個秘密代表使用者發出後續請求。」

其餘的流程、參數、token 型別、redirect、scope……其實都是為了「讓這件事在各種情境下變得安全又一致」。

• OIDC 的切入點：像魔法連結一樣的認證方式

  原文指出 OIDC 的行為本質上與「magic link」非常接近：

1. 把只有使用者能收取的秘密送到某個地方（例如 Email）

2. 使用者拿著那個秘密來證明「對，我就是我」

   OAuth 則是 OIDC 的底層機制，提供了一個安全傳遞與使用秘密的標準框架。

• 為什麼 OAuth 看起來這麼複雜？

  原因不是技術難懂，而是標準化不可避免產生的「雜訊」。作者坦承，標準體系確實像框架而非單一協定，就像 HTML 一樣，並非每個瀏覽器都要支援全部功能。

  複雜不是因為核心難，而是因為：

• 要照顧各種客戶端（web、desktop、mobile）

• 要在不安全環境下保持安全

• 要達成跨服務互通

• 要避免重複發明輪子（雖然大家當時已經造了不少）

筆者心得與啟發

讀完原文，我最大的感觸是：OAuth 被人誤解，是因為大家從它的「流程」開始學，而不是從「它要解決的問題」開始理解。

作者用非常清楚的方式告訴我，OAuth 的目的不是提供某種複雜的安全黑魔法，而只是回答一個很基本的問題：

「我要怎麼把授權安全地交給別人用？」

我也特別喜歡他對 Geoffrey 問題的回應：如果你不知道原始動機，只看協定細節，很容易迷失在技術碎片裡，卻不知道整個機制到底在保護什麼。

實務上，我會建議任何要學 OAuth 的工程師都先回答三個問題：

1. 我到底要委託什麼權限？
2. 我希望哪個第三方代替我執行什麼操作？
3. 這個「秘密」應該在什麼上下文中被安全使用？

當這三點清晰後，OAuth 的機制其實會變得非常直覺。

最後，我很喜歡作者說自己沒有參與 OIDC 標準的編寫：「那種看著孩子自己長大的複雜感」。從這種距離，我也讀到了標準演進背後的人味與歷史。這篇文章對想真正理解 OAuth 的人來說，非常值得一讀。