OAuth2.0是OAuth協定的延續版本，但不向前相容OAuth 1.0，OAuth2.0關注客戶端開發者的簡易性，或透過組織在資源擁有者和HTTP服務商之間的被批准的互動動作代表用戶，要么允許第三方應用程式代表用戶獲得訪問的權限。
OAuth2.0是OAuth協定的延續版本，但不向前相容OAuth 1.0(即完全廢止了OAuth1.0)。 OAuth 2.0關注客戶端開發者的簡易性。要麼透過組織在資源擁有者和HTTP服務商之間的被批准的互動動作代表用戶，要麼允許第三方應用程式代表用戶獲得存取的權限。同時為網路應用，桌面應用和手機，和起居室設備提供專門的認證流程。 2012年10月，OAuth 2.0協議正式發佈為RFC 6749。
前言：
OAuth 1.0已經在IETF（國際互聯網工程任務組），編號是RFC5849
這也標誌著OAuth已經正式成為網際網路標準協定。
OAuth 2.0早已經開始討論建立的草稿。 OAuth2.0很可能是下一代的「使用者驗證和授權」標準。現在百度開放平台，騰訊開放平台等大部分的開放平台都是使用的OAuth 2.0協議作為支撐。
OAuth（開放授權）是一個開放標準，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片，視頻，聯繫人列表），而無需將用戶名和密碼提供給第三方應用。
OAuth
允許使用者提供一個令牌，而不是使用者名稱和密碼來存取他們存放在特定服務提供者的資料。每一個令牌授權一個特定的網站（例如，影片編輯網站)在特定的時段（例如，接下來的2小時內）內存取特定的資源（例如僅僅是某一相簿中的影片）。這樣，OAuth允許使用者授權第三方網站存取他們儲存在另外的服務提供者上的信息，而不需要分享他們的存取許可或他們資料的所有內容。
OAuth是OpenID的一個補充，但完全不同的服務。
OAuth 2.0
是OAuth協定的下一版本，但不向後相容OAuth 1.0。 OAuth 2.0關注客戶端開發者的簡易性，同時為Web應用，桌面應用和手機，和起居室設備提供專門的認證流程。 2012年10月，OAuth 2.0協議正式發佈為RFC 6749 [1] 。
Facebook的新的Graph API只支援OAuth 2.0，Google在2011年3月亦宣布Google API對OAuth 2.0的支援。
認證授權流程：
在認證和授權的過程中涉及的三方包括：
1、服務提供方，使用者使用服務提供方來儲存受保護的資源，如照片，視頻，聯絡人清單。
2、用戶，存放在服務提供者的受保護的資源的擁有者。
3、客戶端，要存取服務提供方資源的第三方應用，通常是網站，例如提供照片列印服務的網站。在認證過程之前，客戶端要向服務提供者申請客戶端標識。
使用OAuth進行認證和授權的流程如下所示:
使用者想要操作存放在服務提供者的資源。
使用者登入用戶端向服務提供者請求一個臨時令牌。
服務提供者驗證客戶端的身分後，授予一個暫存令牌。
客戶端取得臨時令牌後，將使用者引導至服務提供者的授權頁面請求使用者授權。在這個過程中將臨時令牌和客戶端的回呼連線傳送給服務提供者。
使用者在服務提供者的網頁上輸入使用者名稱和密碼，然後授權該客戶端存取所要求的資源。
授權成功後，服務提供者引導使用者返回客戶端的網頁。
用戶端根據臨時令牌從服務提供者取得存取令牌。
服務提供者根據臨時令牌和使用者的授權情況授予客戶端存取令牌。
用戶端使用取得的存取權杖存取存放在服務提供者上的受保護的資源。
簡單歷史回顧
OAuth 1.0在2007年的12月底發布並迅速成為工業標準。
2008年6月，發布了OAuth 1.0 Revision A，這是個稍作修改的修訂版本，主要修正一個安全方面的漏洞。
2010年四月，OAuth 1.0的終於在IETF發布了，協議編號RFC 5849。
OAuth 2.0的草案是在2011年5月初在IETF發布的。
OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords.
OAuth是個安全相關的協議，作用第三方在於，使用戶授權第三方的應用程式存取用戶的web資源，並且不需要向第三方應用程式透露自己的密碼。
OAuth 2.0是個全新的協議，並且不對先前的版本做向後相容，然而，OAuth 2.0保留了與先前版本OAuth相同的整體架構。
這個草案是圍繞著OAuth2.0的需求和目標，歷經了長達一年的討論，討論的參與者來自業界的各個知名公司，包括Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom , Intuit, Mozilla, and Google。
OAuth 2.0的新特性：
6種全新流程
User-Agent Flow – 用戶端運行於使用者代理程式內（典型如web瀏覽器）。
Web Server Flow – 用戶端是web伺服器程式的一部分，透過http request接入，這是OAuth 1.0提供的流程的簡化版本。
Device Flow – 適用於客戶端在受限裝置上執行操作，但是終端使用者單獨接入另一台電腦或裝置的瀏覽器
Username and Password Flow – 這個流程的應用場景是，使用者信任客戶端處理身分憑證，但是仍然不希望客戶端儲存他們的使用者名稱和密碼，這個流程僅在使用者高度信任客戶端時才適用。
Client Credentials Flow – 用戶端適用它的身分憑證去取得access token，這個流程支援2-legged OAuth的場景。
Assertion Flow – 客戶端用assertion去換取access token，例如SAML assertion。
可以透過使用以上的多種流程來實現Native應用程式對OAuth的支援（程式運行於桌面作業系統或行動裝置）
application support (applications running on a desktop or mobile device ) can be implemented using many of the flows above.
持信人token
OAuth 2.0 提供一種無需加密的認證方式，此方式是基於現存的cookie驗證架構，token本身將自己作為secret，透過HTTPS發送，從而替換了透過HMAC和token secret加密並發送的方式，這將允許使用cURL發起APIcall和其他簡單的腳本工具而不需遵循原先的request方式並進行簽署。
簽章簡化：
對於簽章的支持，簽章機制大大簡化，不需要特殊的解析處理，編碼，和對參數進行排序。使用一個secret取代原先的兩個secret。
短期token和長效的身份憑證
原先的OAuth，會發行一個有效期非常長的token(典型的是一年有效期或者無有效期限制)，在OAuth 2.0中， server將發行一個短有效期的access token和長生命期的refresh token。這將允許客戶端無需用戶再次操作而獲取新的access token，並且也限制了access token的有效期。
角色分開
OAuth 2.0將分為兩個角色：
Authorization server負責取得使用者的授權並且發布token。
Resource負責處理API calls。
以上是OAuth 2.0是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
