OAuth2.0的原理介紹

OAuth2.0是一個關於受權（authorization）的開放網絡標準，在全世界獲得普遍應用，目前的版本是2.0版。

• OAuth2.0（開放受權)是一個正式的互聯網標準協議。
• 容許第三方網站在用戶受權的前提下訪問在用戶在服務商那裏存儲的各類信息。而這種受權無需將用戶提供用戶名和密碼提供紿該第三方網站。
• OAuth2.0容許用戶提供一個令牌紿第三方網站，一個令牌對應一個特定的第三方網站，同時該令牌只能在特定的時間內訪問特定的資源。

1. 受權碼模式(authorization code)
2. 簡化模式 (implicit)
3. 密碼模式(resource owner password credentials)
4. 客戶端模式(client credentials)

• 授杈碼模式是功能最完整、流程最嚴密的受權模式
• 簡化模式不經過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了''受權碼"這個步驟
• 密碼模式須要用戶向客戶端提供本身的用戶名和密碼
• 客戶端模式指客戶端以本身的名義，而不是以用戶的名義，向''服務提供商"進行認證

受權碼模式詳解

 

 實現OAuth2.0協議中的必選方法

• 實現重定向的機制
• 實現受權碼的機制
• 實現token發放的機制

 簡介：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流程圖

這是相關「雅虎」站點進行OAuth認證的整個運行流程：
參與者：Application，YAHOO!，User
（1）客戶端在本身站點實現YAHOO!的第三方認證以前，須要到YAHOO!服務提供商申請賬號Consumer Key，YAHOO!經過申請以後，併發放Consumer Key已經對應的Consumer Secret的一套認證賬號，這時候說明該客戶端已經加入了YAHOO服務提供商的認證服務。
（2）獲取Request Token，須要傳遞參數：
          oauth_consumer_key：應用ID
          oauth_nonce：客戶端生成的隨機數
          oauth_signature_method：簽名方式（目前有：HMAC-SHA一、RSA-SHA1與PLAINTEXT等三種）
          oauth_timestamp：時間戳
          oauth_version：OAuth版本號
          xoauth_lang_pref(optional)：
          oauth_callback：
     YAHOO!驗證用戶參數合法，經過驗證，贊成發放Request_Token，返回客戶端參數：
          oauth_token：請求令牌
          oauth_token_secret：令牌對應的密鑰
          oauth_expires_in：令牌過時時間
          xoauth_request_auth_url：
          oauth_callback_confirmed=true
（3）客戶端接收到Request_Token，此時將用戶導向YAHOO!認證頁面，並傳遞參數：Request_Token
          oauth_token：請求令牌
          此時服務提供商接下來「詢問用戶是否給予受權」，用戶贊成受權，服務提供商將用戶重定向客戶端事先傳遞的oauth_callback（重定向URI）地址，並以GET方式傳遞受權碼（oauth_verifier）
（4）客戶端使用Request_Token以及OAuth_Verifier向服務提供商交換Access_Token：傳遞參數：
          oauth_consumer_key：應用ID          
          oauth_signature_method：簽名方式（目前有：HMAC-SHA一、RSA-SHA1與PLAINTEXT等三種）
          oauth_signature：簽名（注意，這一步驟用到了簽名，OAuth簽名的生成，詳看服務提供商OAuth簽名生成文檔，此處提供金山快盤簽名生成）
          oauth_timestamp：時間戳
          oauth_version：OAuth版本號
          oauth_token：Request_Token請求令牌
          oauth_nonce：客戶端生成的隨機數
          oauth_verifier：受權碼
      服務提供商確認簽名匹配，參數準確無誤，授予Access_Token以及Access_Secret，返回客戶端參數：
          oauth_token：Access_Token訪問令牌
          oauth_token_secret：令牌對應密鑰
          oauth_session_handle：用於刷新過時訪問令牌
          oauth_expires_in：令牌過時時間

（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：

騰訊，百度，新浪等開放平臺都普遍使用了OAuth2.0

關於OAuth2.0的術語：
（1） Third-party application：第三方應用程序，又稱」客戶端」（client）； 

（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種