oauth.net/about/introduction/ oauth.net/about/introduction/改編自 Eran Hammer-Lahav 在 2007 年 9 月 5 日發布的 說明 OAuth
OAuth 於 2006 年 11 月左右開始，當時 Blaine Cook 正在開發 Twitter OpenID 執行個體。他與 Chris Messina 取得聯繫，詢問如何使用 OpenID 和 Twitter API 來授權驗證。他們在 CitizenSpace OpenID 會議中與 David Recordon、Larry Halff 和其他人士討論現有解決方案。Larry 當時正在尋找整合 OpenID 至 Ma.gnolia Dashboard Widget 的方式。檢視現有 OpenID 功能和產業慣例後，他們得出結論：API 存取授權並無公開標準。線上線下的對話持續了幾個月。
2007 年 4 月，建立了一個 Google 小組，由一群實作者撰寫一項公開協定的建議書。結果顯示這個問題並非 OpenID 獨有，而當 Google 的 DeWitt Clinton 得知這項專案時，他表示有興趣支持這個工作，即使僅作為利害關係人。2007 年 7 月，團隊起草了初始規格，並讓所有有興趣參與的人開放加入小組。2007 年 10 月 3 日發布了 OAuth Core 1.0 最終草案。
許多豪華汽車現今配備有代客泊車鑰匙。這是一種特殊鑰匙，提供給停車服務員，不同於一般的鑰匙，無法讓汽車行駛超過一兩英里。有些代客泊車鑰匙無法打開後車廂，而有些則會封鎖車內手機通訊錄的存取。無論代客泊車鑰匙施加哪些限制，這個概念都非常聰明。您透過一把特殊鑰匙授予他人有限存取您的車輛權限，而自己則使用一般鑰匙解除所有鎖定。
每天都有新的網站上線，提供系統功能整合服務來自其他網站。例如線上相片印製、使用通訊錄查找朋友的社交網路，以及系統開發用 API 來建置自己版本的熱門網站桌面應用程式。這些都是相當棒的服務，但有些實作上，不是那麼好的方面，在於它會要求您提供使用者名稱及密碼給另一個網站。當您同意分享您的機密憑證時，不單只是讓其他人知道您的密碼（當然，您也使用相同的密碼進行網路線上交易），您也授予他們完全存取權，並可針對您的資訊進行任何處置。他們可以執行任何他們想要做的事，甚至可以變更密碼並將您鎖在門外。
OAuth 解決的就是這個問題。它容許您（使用者）授予存取權限給一個網站（服務供應商），以存取您的私人資源，到另一個網站（消費者）（切勿與使用者搞混）。OpenID 的功能是以單一識別碼簽入許多網站，而 OAuth 的功能則是在完全不分享識別碼（或是其機密部分）的情況下，提供存取您的資料之功能。
OAuth 並非 OpenID 延伸功能，在規格層面，僅與 OpenID 共享少數功能：一些常見作者，以及兩者均為驗證及存取控制領域中的開放規格。為何 OAuth 不是 OpenID 延伸功能？這おそらく是該群組最常被問到的問題。答案很簡單，OAuth 嘗試為開發人員提供標準化方式，以便透過 API 提供他們的服務，而不強迫他們的使用者揭露密碼（及其他憑證）。如果 OAuth 依賴於 OpenID，只有 OpenID 服務才能使用它，儘管 OpenID 很棒，但在許多應用程式中它並不適合或不受歡迎。這並不代表您無法同時使用這兩個功能。OAuth 處理取得使用者授予的存取權限，而 OpenID 則處理確保使用者真的如同他們所聲稱的那樣。它們應該可以合作無間。
每個人。如果您是網路開發人員，我們希望是您。
不是。OAuth 是許多良好建立的產業協定的標準化和整合智慧。它類似於目前已在使用的其他協定（Google AuthSub、AOL OpenAuth、Yahoo BBAuth、即將推出的 API、Flickr API、Amazon Web Services API 等）。每個協定都提供一種獨特的交換使用者憑證給存取令牌或代用券的方法。OAuth 的建立是透過仔細研究每一個這些協定、萃取出最佳慣例及共性而成，它將允許新的實作，以及讓現有服務順利過渡，以支援 OAuth。
在 OAuth 比其他某些通訊協定和服務發展得更成熟的領域是其直接處理非網站服務的方式。OAuth 已建置能支援桌上型電腦應用程式、行動裝置、機上盒，當然還有網站。目前許多通訊協定使用硬編碼在您的軟體中的共同密鑰來進行通訊，當嘗試存取您私人資料的服務為開放原始碼時，這就會造成問題。