-
OAuth2.0
鎖定
OAuth2.0是OAuth協議的延續版本，但不向前兼容OAuth 1.0(即完全廢止了OAuth1.0)。 OAuth 2.0關注客户端開發者的簡易性。要麼通過組織在資源擁有者和HTTP服務商之間的被批准的交互動作代表用户，要麼允許第三方應用代表用户獲得訪問的權限。同時為Web應用，桌面應用和手機，和智能家居設備提供專門的認證流程。
2012年10月，OAuth 2.0協議正式發佈為RFC 6749
[1]
。
- 中文名
- 開放授權
- 外文名
- OAuth2.0
- 定 義
- 協議的下一版本
- 簡易性
- OAuth1.0。 OAuth 2.0
- 編 號
- RFC6749
- 應用領域
- 計算機網路、認證
- 娛 樂
- 視頻
OAuth2.0前言
OAuth 1.0已經在IETF（國際互聯網工程任務組），編號是RFC5849
這也標誌着OAuth已經正式成為互聯網標準協議。
OAuth（開放授權）是一個開放標準，允許用户讓第三方應用訪問該用户在某一網站上存儲的私密的資源（如照片，視頻，聯繫人列表），而無需將用户名和密碼提供給第三方應用。
OAuth
允許用户提供一個令牌，而不是用户名和密碼來訪問他們存放在特定服務提供者的數據。每一個令牌授權一個特定的網站（例如，視頻編輯網站）在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。這樣，OAuth允許用户授權第三方網站訪問他們存儲在另外的服務提供者上的信息，而不需要分享他們的訪問許可或他們數據的所有內容。
OAuth是OpenID的一個補充，但是完全不同的服務。
Facebook的新的Graph API只支持OAuth 2.0，Google在2011年3月亦宣佈Google API對OAuth 2.0的支持。
OAuth 2.0
是OAuth協議的下一版本，但不向後兼容OAuth 1.0。 OAuth 2.0關注客户端開發者的簡易性，同時為Web應用，桌面應用和手機，和起居室設備提供專門的認證流程。
[1]
OAuth2.0認證授權過程
在認證和授權的過程中涉及的三方包括：
1、服務提供方，用户使用服務提供方來存儲受保護的資源，如照片，視頻，聯繫人列表。
2、用户，存放在服務提供方的受保護的資源的擁有者。
使用OAuth進行認證和授權的過程如下所示:
用户想操作存放在服務提供方的資源。
用户登錄客户端向服務提供方請求一個臨時令牌。
服務提供方驗證客户端的身份後，授予一個臨時令牌。
客户端獲得臨時令牌後，將用户引導至服務提供方的授權頁面請求用户授權。在這個過程中將臨時令牌和客户端的回調連接發送給服務提供方。
用户在服務提供方的網頁上輸入用户名和密碼，然後授權該客户端訪問所請求的資源。
授權成功後，服務提供方引導用户返回客户端的網頁。
客户端根據臨時令牌從服務提供方那裏獲取訪問令牌。
服務提供方根據臨時令牌和用户的授權情況授予客户端訪問令牌。
客户端使用獲取的訪問令牌訪問存放在服務提供方上的受保護的資源。
OAuth2.0簡單歷史回顧
OAuth 1.0在2007年的12月底發佈並迅速成為工業標準。
2008年6月，發佈了OAuth 1.0 Revision A，這是個稍作修改的修訂版本，主要修正一個安全方面的漏洞。
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 2.0是個全新的協議，並且不對之前的版本做向後兼容，然而，OAuth 2.0保留了與之前版本OAuth相同的整體架構。
這個草案是圍繞着 OAuth2.0的需求和目標，歷經了長達一年的討論，討論的參與者來自業界的各個知名公司，包括Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google。
OAuth 2.0的新特性：
OAuth2.06種全新流程
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。
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。
- 參考資料
-
- 1. The OAuth 2.0 Authorization Framework ．IETF Tools[引用日期2014-06-12]
