oauth2.0是乙個關於授權（authorization）的開放網路標準，在全世界得到廣泛應用，目前的版本是2.0版。
授權碼模式(authorization code)
簡化模式 (implicit)
密碼模式(resource owner password credentials)
客戶端模式(client credentials)
簡介：oauth是乙個關於授權（authorization）的開放網路標準，在全世界得到廣泛應用（典型：第三方登入），目前的版本是2.0版。
沒有oauth的時代：
假設我們有這麼乙個場景：有三個角色，分別是「使用者」，「第三方應用」，「服務提供商，比如google」
使用者有很多**都存放在google伺服器，這時候，使用者需要借助第三方應用「雲沖印」，將存放在google伺服器的**列印出來，那麼此時我們正處於沒有oauth的時代，這時候，使用者登入第三方應用「雲沖印」之後，就得需要將使用者在google的帳號和密碼提供給「雲沖印」，這時候「雲沖印」拿著使用者提供的google帳號和密碼，登入到google伺服器，再而獲取使用者的**，接著後續的列印工作。
那麼上面是乙個模擬的場景，在沒有oauth的時代，我們也只能這麼做，那麼會導致什麼樣的問題發生，缺陷如下：
嚴重缺點:
（1）雲沖印完全儲存使用者密碼，導致使用者的google帳號不安全；
（2）客戶端獲取使用者儲存在google伺服器的所有資料，使用者沒法限制第三方應用「雲沖印」的授權範圍和有效期；
（3）使用者只有修改密碼，才能收回賦予第三方應用「雲沖印」的權利；
（4）最為嚴重：「雲沖印」站點遭遇攻擊，使用者密碼洩露，意味著使用者在google的資訊洩露；
基於以上幾個缺陷，oauth誕生了。
oauth作用：就是讓"客戶端」（第三方應用：上文的雲沖印）安全可控地獲取"使用者"的授權，與"服務提供商"進行互動。
目前oauth有三個版本：oauth1.0，oauth1.0a，oauth2.0
oauth1.0
用一副圖來解釋oauth1.0的整個執行流程如圖1所示：
圖1：oauth1.0流程圖
（5）令牌過期，重新重新整理令牌
與(4)區別唯一引數：oauth_session_handle，不需要傳遞授權碼：oauth_verifier，yahoo!重新返回access_token以及金鑰access_token_secret
注意：這裡的oauth_timestamp和oauth_nonce是為防止重放攻擊而設定的。具體的來講：請求者不能在一段時間（伺服器允許的客戶端和服務端的時間差）內傳送同樣的請求兩次或以上，如果在這個時間段之後再次發生這個請求，則會因為超出服務端允許的時間差而被拒絕。
2009 年 4 月 23 日， oauth 宣告了乙個 1.0 協議的安全漏洞。該漏洞影響了 oauth 1.0 核心規範第 6 節的oauth 的認證流程（也稱作 3 階段 oauth ）， oauth core 協議 1.0a 版本解決了這一問題。
oauth 1.0可能發布地太快了，因此廣受批評。之後很快就出現了與之競爭的wrap（web資源授權協議），它很快地進行了標準化，成為oauth的對手。從那時開始，oauth工作小組就開始著手建立oauth 2.0。
oauth2.0：
（2）http service：http服務提供商，簡稱」服務提供商」，；
（3）resource owner：資源所有者，又稱」使用者"（user）；
（4）user agent：使用者**，指瀏覽器；
（5）authorization server：認證伺服器，服務提供商專門用來處理認證的伺服器；
（6）resource server：資源伺服器，服務提供商存放使用者資源的伺服器。它與認證伺服器可以是同一臺伺服器，也可以是不同的伺服器；
執行流程： （如下圖2所示）
（a）使用者開啟客戶端以後，客戶端要求使用者給予授權。
（b）使用者同意給予客戶端授權。
（c）客戶端使用上一步獲得的授權，向認證伺服器申請令牌。
（d）認證伺服器對客戶端進行認證以後，確認無誤，同意發放令牌。
（e）客戶端使用令牌，向資源伺服器申請獲取資源。
（f）資源伺服器確認令牌無誤，同意向客戶端開放資源。
圖2：oauth2.0執行簡易流程
b（授權）為最關鍵的步驟！
客戶端的授權模式（4種）：
（1）授權碼模式（authorization code）
（2）簡化模式（implicit）
（3）密碼模式（resource owner password credentials）
（4）客戶端模式（client credentials）
其中：授權碼模式（authorization code）是功能最完整、流程最嚴密的授權模式。它的特點就是通過客戶端的後台伺服器，與"服務提供商"的認證伺服器進行互動。
當然，並不是所有人對oauth2.0都投贊成票，有興趣可以看看：oauth 2.0對web有害嗎？
關於oauth1.0和2.0的相關區別小結：
(1)1.0每次請求都需要簽名，2.0更簡潔，不需要簽名了
(2)1.0:request_token->authorization_code; authorization_code->access_token 2.0:authorization_code->access_token
(3)1.0每個token都需要加密，2.0則不需要，這樣不就不安全了，但是2.0要求使用https（是由ssl+http協議構建的可進行加密傳輸、身份認證的網路協議。如果不是登陸到一些帳戶和密碼時，沒什麼用，只有需要登陸密碼時這樣候它的作用就非常大了。）協議，安全性更高一籌
(4)2.0有4種授權模式，1.0只有1種
簡單介紹 Oauth2 0 原理
有兩家網際網路企業 a 和 b，其中 b 是一家提供相片雲儲存的公司。使用者可以把相片上傳到 b 上長期儲存，然後可以在不同的裝置上檢視。某一天，a 和 b 談成了一項合作 希望使用者在使用 a 時，也可以 他在 b 的相片。這個技術上要怎麼實現呢？選項一 由 b 提供乙個介面 get photos...
OAuth 2 0 基本介紹
前言 最近討論園子裡是否真末落的話題那可是沸沸揚揚啊！我就不湊這個熱鬧了！在此吐點最近在整的東西出來給大家！廣大開發者和使用者登入平台後，就可以使用平台提供的開放api介面，建立應用從微博系統獲取資訊，或將新的資訊傳播到整個微博系統中，豐富多樣的api介面和應用，加上您的智慧型，將創造出無窮的應用和...
OAuth2 0 基礎介紹
1 應用場景 2 角色說明 3 oauth2.0 概述 4 協議流程 5 四種授權模式 6 授權碼模式 1 resource owner資源擁有者，能夠許可對受保護資源的訪問許可權的實體。當資源所有者是個人時，它被稱為終端使用者。2 resource server 資源伺服器，管理受保護資源的伺服器...