OAuth2.0是什麼?

OAuth2.0是OAuth協議的下一版本，但不向後相容OAuth 1.0即完全廢止了OAuth1.0。 OAuth 2.0關注用戶端開發人員的簡易性。要麼通過組織在資源擁有者和HTTP服務商之間的被獲批准的互動動作代表使用者，要麼允許第三方應用代表使用者獲得訪問的許可權。同時為Web應用，案頭應用和手機，和起居室裝置提供專門的認證流程。2012年10月，OAuth 2.0協議正式發布為RFC 6749。

Facebook的新的Graph API只支援OAuth 2.0，Google在2011年3月亦宣布Google API對OAuth 2.0的支援。 認證授權過程

在認證和授權的過程中涉及的三方包括： 服務提供者，使用者使用服務提供者來儲存受保護的資源，如照片，視頻，連絡人清單。 使用者，存放在服務提供者的受保護的資源的擁有者。 用戶端，要訪問服務提供者資源的第三方應用，通常是網站，如提供照片列印服務的網站。在認證過程之前，用戶端要向服務提供者申請用戶端標識。

使用OAuth進行認證和授權的過程如下所示:

使用者想操作存放在服務提供者的資源。 使用者登入用戶端向服務提供者請求一個臨時令牌。

服務提供者驗證用戶端的身份後，授予一個臨時令牌。

用戶端獲得臨時令牌後，將使用者引導至服務提供者的授權頁面請求使用者授權。在這個過程中將臨時令牌和用戶端的回調串連發送給服務提供者。

使用者在服務提供者的網頁上輸入使用者名稱和密碼，然後授權該用戶端訪問所請求的資源。 授權成功後，服務提供者引導使用者返回用戶端的網頁。

用戶端根據臨時令牌從服務提供者那裡擷取存取權杖。服務提供者根據臨時令牌和使用者的授權情況授予用戶端存取權杖。

用戶端使用擷取的存取權杖訪問存放在服務提供者上的受保護的資源。 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的支援（程式運行於案頭作業系統或行動裝置） 持信人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。