原文地址：http://www.sanjinbest.com/blog/b6ec839d56c04ca387b956871d0edf38.html

引言：剛剛參加工作的時候接到的第一個任務(wù)就是接入新浪的聯(lián)合登錄功能，當(dāng)時新浪用的還是oauth1.0協(xié)議。接入的時候沒有對oauth協(xié)議有過多的了解，只是按照開放平臺的接入流程進行開發(fā)没卸，當(dāng)時還在想這么麻煩就是為了作一個登錄功能？（為當(dāng)年的無知汗顏...）璃氢。再后來上家公司需要開發(fā)一套自己的基于oauth2.0的聯(lián)合登錄功能页屠，粗粗的看了下oauth2.0協(xié)議流程纵穿，自以為了解了便開始設(shè)計開發(fā)如迟，現(xiàn)在來看真是漏洞無數(shù)笆蘸痢（幸好現(xiàn)在功能已經(jīng)下線）。最近在現(xiàn)家公司要作部門內(nèi)部分享殷勘，所以打算好好的研究一下oauth2.0協(xié)議此再。

以下內(nèi)容為個人閱讀《rfc6749》文檔及網(wǎng)上資料整理，如有問題歡迎大家提出玲销。
好输拇，廢話少說，開整痒玩。

1、OAuth是什么议慰？

首先先了解一下什么oauth協(xié)議蠢古，主要解決了什么問題。
先給大家舉個栗子

小新現(xiàn)在想要使用一個“在線打印服務(wù)”來打印一些照片别凹，同時小新的照片都存儲在了“云網(wǎng)盤”上草讶，按照傳統(tǒng)的方式小新要怎么做呢？

1炉菲、將照片從“云網(wǎng)盤”上down下來堕战，在上傳到“在線打印服務(wù)”，然后開始打印拍霜。
2嘱丢、下載/上傳太麻煩了，小新可以直接把“云網(wǎng)盤”的賬號和密碼告訴“在線打印服務(wù)”祠饺，由“在線打印服務(wù)”下載照片在上傳越驻。

對于上面的兩種方法，方法一太麻煩但是相對于小新來說是安全的；方法二對于小新是比較方便缀旁，但是將賬號密碼告訴了“在線打印服務(wù)”就相當(dāng)于把所有的“云網(wǎng)盤”資料交給了它记劈，這肯定是不可取的。

所以并巍，為了解決類似上面的問題目木，Oauth協(xié)議誕生了。

OAuth 即 Open standard for Authorization
OAuth是一個網(wǎng)絡(luò)開放協(xié)議懊渡。為保證用戶資源的安全授權(quán)提供了簡易的標準

oauth的好處：

• 允許用戶授權(quán)第三方網(wǎng)站或應(yīng)用刽射，訪問用戶存儲在其它網(wǎng)站上的資源，而不需要將用戶名和密碼提供給第三方網(wǎng)站或分享他們數(shù)據(jù)的內(nèi)容
• 對于用戶:免去了繁瑣的注冊過程,降低了注冊成本,提高了用戶體驗
• 對于消費方:簡化自身會員系統(tǒng)的同時又能夠帶來更多的用戶和流量距贷。
• 對于服務(wù)提供者:圍繞自身進行開發(fā),增加用戶粘性

目前oauth和版本是2.0即oauth2.0柄冲，而且不向下兼容。本文章主要針對oauth2.0進行講解忠蝗。

2现横、Oauth2.0協(xié)議流程

2.1 角色

在介紹協(xié)議流程之前先要說明一下oauth2.0定義的幾個角色：

• resource owner：資源所有者，這里可以理解為用戶阁最。
• client：客戶端戒祠，可以理解為一個第三方的應(yīng)用程序。 resource server：資源服務(wù)器速种，它存儲用戶或其它資源姜盈。
• authorization server：授權(quán)服務(wù)器，它認證resource owner的身份配阵，為 resource owner提供授權(quán)審批流程馏颂，并最終頒發(fā)授權(quán)令牌(Access Token)。
• useragent：用戶代理棋傍，這里可以理解為“瀏覽器”救拉。

這里面有個需要注意的地方，這里只是在邏輯上把authorization server與resource server區(qū)分開來瘫拣；在物理上亿絮，authorization server與resource server的功能可以由同一個服務(wù)器來提供服務(wù)。

（A）用戶打開客戶端以后麸拄，客戶端要求用戶給予授權(quán)派昧。
（B）用戶同意給予客戶端授權(quán)。
（C）客戶端使用上一步獲得的授權(quán)拢切，向認證服務(wù)器申請令牌蒂萎。
（D）認證服務(wù)器對客戶端進行認證以后，確認無誤淮椰，同意發(fā)放令牌岖是。
（E）客戶端使用令牌帮毁，向資源服務(wù)器申請獲取資源。
（F）資源服務(wù)器確認令牌無誤豺撑，同意向客戶端開放資源烈疚。

上面六個步驟之中，B是關(guān)鍵聪轿，即用戶怎樣才能給于客戶端授權(quán)爷肝。有了這個授權(quán)以后，客戶端就可以獲取令牌陆错，進而憑令牌獲取資源灯抛。
下面就介紹一下oauth2.0獲取授權(quán)的幾種方式。

3音瓷、Oauth2.0授權(quán)模式

3.1 應(yīng)用程序注冊(Application Registration)

對于一個應(yīng)用程序來說对嚼，如果它想要使用OAuth，那么首先它要在服務(wù)提供商那里注冊绳慎。
應(yīng)用程序要提供：

• 應(yīng)用程序名稱(Application Name)
• 應(yīng)用程序網(wǎng)站(Application Website)
• 回調(diào)URL(Redirect URI or Callback URL)
  在用戶同意授權(quán)(或者拒絕)之后纵竖，服務(wù)提供商會將用戶重新導(dǎo)向這個Callback URL，這個Callback URL要來負責(zé)處理授權(quán)碼或者訪問令牌杏愤。

應(yīng)用程序注冊完成之后靡砌，服務(wù)提供商會頒發(fā)給應(yīng)用程序一個“客戶端認證信息(client credentials)”。
Client Credential包括：

• Client ID提供給服務(wù)提供商珊楼，用于識別應(yīng)用程序用于構(gòu)建提供給用戶請求授權(quán)的URL
• Client Secret提供給服務(wù)提供商通殃，用于驗證應(yīng)用程序
  只有應(yīng)用程序和服務(wù)提供商兩者可知

3.2 授權(quán)模式

oauth2.0提供了四種授權(quán)模式，開發(fā)者可以根據(jù)自己的業(yè)務(wù)情況自由選擇厕宗。

• 授權(quán)碼授權(quán)模式（Authorization Code Grant）
• 隱式授權(quán)模式（Implicit Grant）
• 密碼授權(quán)模式（Resource Owner Password Credentials Grant）
• 客戶端憑證授權(quán)模式（Client Credentials Grant）

3.2.1 授權(quán)碼授權(quán)模式（Authorization Code Grant）

流程介紹

（A）用戶訪問客戶端画舌，客戶端將用戶引導(dǎo)向認證服務(wù)器。
（B）用戶選擇是否給予客戶端授權(quán)已慢。
（C）如用戶給予授權(quán)曲聂，認證服務(wù)器將用戶引導(dǎo)向客戶端指定的redirection uri，同時加上授權(quán)碼code蛇受。
（D）客戶端收到code后句葵，通過后臺的服務(wù)器向認證服務(wù)器發(fā)送code和redirection uri厕鹃。
（E）認證服務(wù)器驗證code和redirection uri兢仰，確認無誤后，響應(yīng)客戶端訪問令牌（access token）和刷新令牌（refresh token）剂碴。
請求示例
（A）步驟：客戶端申請認證的URI

https://www.example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read&state=xxx

參數(shù)說明：

response_type：授權(quán)類型把将，必選項，此處的值固定為"code"　　
client_id：客戶端的ID忆矛，必選項　　
redirect_uri：重定向URI察蹲，必選項　　
scope：申請的權(quán)限范圍请垛，可選項　　
state：任意值，認證服務(wù)器會原樣返回,用于抵制CSRF(跨站請求偽造)攻擊洽议。

（C）步驟：服務(wù)器回應(yīng)客戶端的URI

https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xxx

參數(shù)說明：

code：授權(quán)碼宗收，必選項。授權(quán)碼有效期通常設(shè)為10分鐘亚兄，一次性使用混稽。該碼與客戶端ID、重定向URI以及用戶审胚，是一一對應(yīng)關(guān)系匈勋。　　
state：原樣返回客戶端傳的該參數(shù)的值膳叨。

（D）步驟：客戶端向認證服務(wù)器申請令牌

https://www.example.com/v1/oauth/token?client_id=CLIENT_ID&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

參數(shù)說明：

client_id：表示客戶端ID洽洁，必選項。　　
grant_type：表示使用的授權(quán)模式锡溯，必選項圾亏，此處的值固定為"authorization_code"×祝　　
code：表示上一步獲得的授權(quán)碼，必選項悉默〕腔恚　　
redirect_uri：表示重定向URI，必選項抄课，且必須與A步驟中的該參數(shù)值保持一致唱星。

注意：協(xié)議里沒有提及client_secret參數(shù)，建議可以使用此參數(shù)進行客戶端的二次驗證跟磨。
（E）步驟：響應(yīng)（D）步驟的數(shù)據(jù)

{ "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

參數(shù)說明：

access_token：訪問令牌间聊，必選項〉志校　　
token_type：令牌類型哎榴，該值大小寫不敏感，必選項僵蛛∩序颍　　
expires_in：過期時間，單位為秒充尉。如果省略該參數(shù)飘言，必須其他方式設(shè)置過期時間⊥障溃　　
refresh_token：更新令牌姿鸿，用來獲取下一次的訪問令牌谆吴，可選項】猎ぃ　　
scope：權(quán)限范圍句狼，如果與客戶端申請的范圍一致，此項可省略热某。

使用場景

授權(quán)碼模式是最常見的一種授權(quán)模式鲜锚，在oauth2.0內(nèi)是最安全和最完善的。
適用于所有有Server端的應(yīng)用苫拍，如Web站點芜繁、有Server端的手機客戶端。
可以得到較長期限授權(quán)绒极。

3.2.2 隱式授權(quán)模式（Implicit Grant）

流程介紹

（A）客戶端將用戶引導(dǎo)向認證服務(wù)器骏令。
（B）用戶決定是否給于客戶端授權(quán)。
（C）假設(shè)用戶給予授權(quán)垄提，認證服務(wù)器將用戶導(dǎo)向客戶端指定的”重定向URI"榔袋，并在URI的Hash部分包含了訪問令牌。
（D）瀏覽器向資源服務(wù)器發(fā)出請求铡俐，其中不包括上一步收到的Hash值凰兑。
（E）資源服務(wù)器返回一個網(wǎng)頁，其中包含的代碼可以獲取Hash值中的令牌审丘。
（F）瀏覽器執(zhí)行上一步獲得的腳本吏够，提取出令牌。
（G）瀏覽器將令牌發(fā)給客戶端滩报。
請求示例
（A）步驟：客戶端發(fā)出請求

https://www.example.com/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read&state=xxx

參數(shù)說明

response_type：授權(quán)類型锅知，此處的值固定為"token"，必選項脓钾∈鄱茫　　
client_id：客戶端的ID，必選項可训〔茫　　
redirect_uri：重定向的URI，必選項握截》裳拢　　
scope：權(quán)限范圍，可選項川蒙⊙晾鳎　　
state: 任意值长已，認證服務(wù)器會原樣返回,用于抵制CSRF(跨站請求偽造)攻擊畜眨。

（C）步驟：認證服務(wù)器響應(yīng)客戶端的請求url

https://www.example.com/callback#access_token =ACCESS_TOKEN&state=xyz&token_type=example&expires_in=3600&state=xxx

參數(shù)說明

access_token：訪問令牌昼牛，必選項】的簦　　
token_type：令牌類型贰健，該值大小寫不敏感，必選項恬汁×娲唬　　
expires_in：過期時間，單位為秒氓侧。如果省略該參數(shù)脊另，必須其他方式設(shè)置過期時間≡枷铮　　
scope：權(quán)限范圍偎痛，如果與客戶端申請的范圍一致，此項可省略独郎〔嚷螅　　
state：如果客戶端的請求中包含這個參數(shù)，認證服務(wù)器的回應(yīng)也必須一模一樣包含這個參數(shù)氓癌。

使用場景

適用于所有無Server端配合的應(yīng)用
如手機/桌面客戶端程序谓谦、瀏覽器插件。
基于JavaScript等腳本客戶端腳本語言實現(xiàn)的應(yīng)用贪婉。

注意：因為Access token是附著在 redirect_uri 上面被返回的反粥，所以這個 Access token就可能會暴露給資源所有者或者設(shè)置內(nèi)的其它方（對資源所有者來說，可以看到redirect_uri疲迂，對其它方來說星压，可以通過監(jiān)測瀏覽器的地址變化來得到 Access token）。

3.2.3 密碼模式（Resource Owner Password Credentials Grant）

流程介紹

（A）用戶向客戶端提供用戶名和密碼鬼譬。
（B）客戶端將用戶名和密碼發(fā)給認證服務(wù)器娜膘，向后者請求令牌。
（C）認證服務(wù)器確認無誤后优质，向客戶端提供訪問令牌竣贪。
請求示例
（B）步驟：客戶端發(fā)出https請求

https://www.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

參數(shù)說明

grant_type：授權(quán)類型，此處的值固定為"password"巩螃，必選項演怎。　　
username：用戶名避乏，必選項爷耀。　　
password：用戶的密碼拍皮，必選項歹叮∨芎迹　　
scope：權(quán)限范圍，可選項咆耿。

（C）步驟：向客戶端響應(yīng)（B）步驟的數(shù)據(jù)

{ "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" }

參數(shù)說明

access_token：訪問令牌德谅，必選項∪荩　　
token_type：令牌類型窄做，該值大小寫不敏感，必選項慰技⊥终担　　
expires_in：過期時間，單位為秒吻商。如果省略該參數(shù)庸汗，必須其他方式設(shè)置過期時間∈直ǎ　　
refresh_token：更新令牌蚯舱，用來獲取下一次的訪問令牌，可選項掩蛤。

使用場景

這種模式適用于用戶對應(yīng)用程序高度信任的情況枉昏。比如是用戶操作系統(tǒng)的一部分。
認證服務(wù)器只有在其他授權(quán)模式無法執(zhí)行的情況下揍鸟，才能考慮使用這種模式兄裂。

3.2.4 客戶端憑證模式（Client Credentials Grant）

流程介紹

（A）客戶端向認證服務(wù)器進行身份認證，并要求一個訪問令牌阳藻。
（B）認證服務(wù)器確認無誤后晰奖，向客戶端提供訪問令牌。
請求示例
（A）步驟：客戶端發(fā)送https請求

https://www.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID

參數(shù)說明

granttype：表示授權(quán)類型腥泥，此處的值固定為"client_credentials"匾南，必選項』淄猓　　scope：表示權(quán)限范圍蛆楞，可選項。

（B）步驟：向客戶端響應(yīng)（A）步驟的數(shù)據(jù)

{ "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "example_parameter":"example_value" }

參數(shù)說明：

access_token：訪問令牌夹厌，必選項豹爹。　　
token_type：令牌類型矛纹，該值大小寫不敏感臂聋，必選項。　　
expires_in：過期時間孩等，單位為秒艾君。如果省略該參數(shù)，必須其他方式設(shè)置過期時間瞎访。　　
example_parameter：其它參數(shù)吁恍，可選項扒秸。 

使用場景

客戶端模式應(yīng)用于應(yīng)用程序想要以自己的名義與授權(quán)服務(wù)器以及資源服務(wù)器進行互動。
例如使用了第三方的靜態(tài)文件服務(wù)

3.2.5 刷新TOKEN

從上面的四種授權(quán)流程可以看出冀瓦，最終的目的是要獲取用戶的授權(quán)令牌（access_token）伴奥。而且授權(quán)令牌（access_token）的權(quán)限也非常之大，
所以在協(xié)議中明確表示要設(shè)置授權(quán)令牌（access_token）的有效期翼闽。那么當(dāng)授權(quán)令牌（access_token）過期要怎么辦呢拾徙，協(xié)議里提出了一個刷新token的流程。
流程介紹

（A）--（D）通過授權(quán)流程獲取access_token感局，并調(diào)用業(yè)務(wù)api接口尼啡。
（F）當(dāng)調(diào)用業(yè)務(wù)api接口時響應(yīng)“Invalid Token Error”時。
（G）調(diào)用刷新access_token接口询微，使用參數(shù)refresh_token（如果平臺方提供崖瞭，否則需要用戶重新進行授權(quán)流程）。
（H）響應(yīng)最新的access_token及refresh_token撑毛。
請求示例
（G）步驟：客戶端調(diào)用刷新token接口

https://www.example.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

參數(shù)說明

client_id：客戶端的ID书聚，必選項≡宕疲　　
client_secret：客戶端的密鑰雌续，必選項】韬迹　　
grant_type：表示使用的授權(quán)模式驯杜，此處的值固定為"refreshtoken"，必選項做个⊥щ龋　　refresh_token：表示早前收到的更新令牌，必選項叁温。

（H）步驟：響應(yīng)客戶端數(shù)據(jù)

{ "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

參數(shù)說明

access_token：訪問令牌再悼，必選項∠サ　　
token_type：令牌類型冲九，該值大小寫不敏感，必選項≥杭椋　　
expires_in：過期時間丑孩，單位為秒。如果省略該參數(shù)灭贷，必須其他方式設(shè)置過期時間温学。　　
refresh_token：更新令牌甚疟，用來獲取下一次的訪問令牌仗岖，可選項±姥　　
scope：權(quán)限范圍轧拄，如果與客戶端申請的范圍一致，此項可省略讽膏。

說明：建議將access_token和refresh_token的過期時間保存下來檩电，每次調(diào)用平臺方的業(yè)務(wù)api前先對access_token和refresh_token進行一下時間判斷，如果過期則執(zhí)行刷新access_token或重新授權(quán)操作府树。refersh_token如果過期就只能讓用戶重新授權(quán)俐末。

好，到此oauth2.0的四種授權(quán)流程及令牌的刷新流程已經(jīng)介紹完了奄侠，下面來從oauth2.0的安全性上來介紹一下鹅搪。

4、Oauth2.0安全性

4.1 oauth2.0漏洞安全回顧

oauth2.0協(xié)議本身設(shè)計是安全的遭铺，但是不同的開放平臺開發(fā)者能力參差不齊丽柿，在開發(fā)過程中沒有嚴格按照協(xié)議進行開發(fā)，或?qū)α鞒讨械膮?shù)校驗不完整魂挂，造成了一些流程上的漏洞甫题。

4.1.1 安全漏洞回顧之授權(quán)碼授權(quán)模式（授權(quán)流程參照前面的介紹）

漏洞：針對應(yīng)用方csrf劫持第三方賬號
wooyun案例：

• 2012-11-10 WooYun: 優(yōu)酷網(wǎng)存在賬號被劫持風(fēng)險
• 2013-01-07 WooYun: 大麥網(wǎng)存在帳號被劫持風(fēng)險

• 2013-03-01 WooYun: 美麗說oauth漏洞可劫持賬號

  
  
  
  

  針對code參數(shù)的Authorization Code Grant攻擊；以及和rfc6749的流程圖關(guān)系
  漏洞成因：

主要的漏洞原因是redirect_uri中的code參數(shù)沒有和當(dāng)前客戶端的狀態(tài)綁定涂召，攻擊者可以通過發(fā)送預(yù)先獲取好的code參數(shù)到受害者電腦坠非，導(dǎo)致導(dǎo)致受害者當(dāng)前登錄的應(yīng)用方賬號被綁定到攻擊者指定的平臺方（如微博）帳號上。

解決方案：

應(yīng)用方要預(yù)防這種csrf劫持賬號果正，加入state參數(shù)是比較簡單的通行方法炎码。根據(jù)rfc6749 章節(jié)10.12，該值既不可預(yù)測秋泳，又必須可以證明應(yīng)用（client）和和當(dāng)前第三方網(wǎng)站的登錄認證狀態(tài)存在關(guān)聯(lián)（如果存在過期時間更好）潦闲。一種簡單的方法是：隨機算一個字符串，然后保存在session迫皱，回調(diào)時檢查state參數(shù)和session里面的值歉闰。而平臺方也要在回調(diào)時，支持應(yīng)用方的state參數(shù)（當(dāng)然如果允許redirect_uri參數(shù)中帶應(yīng)用方自己的防csrf參數(shù)，其實也可以）和敬。同時在使用code獲取access_token成功后凹炸，進行access_token與授權(quán)用戶綁定時，盡量不要直接與當(dāng)前登錄用戶進行綁定昼弟。但嚴格來講啤它，僅有state參數(shù)，其實還不夠舱痘，還需要結(jié)合rfc6749 章節(jié)3.3（發(fā)放有業(yè)務(wù)接口僅限范圍的令牌）提到的防御手段变骡。

4.1.2 安全漏洞回顧之隱式授權(quán)模式（授權(quán)流程參照前面的介紹）

漏洞：針對存儲型xss劫持用戶的access_token
wooyun案例：

• 2012-04-15 WooYun: 人人網(wǎng)Oauth 2.0授權(quán)可導(dǎo)致用戶access_token泄露
• 2012-09-25 WooYun: QQ互聯(lián)開放平臺QQ登陸oauth授權(quán)接口可以劫持access_token

• 2012-09-25 WooYun: 百度開放平臺oauth授權(quán)接口可以劫持access_token

  
  
  
  

  漏洞成因：

隱式授權(quán)模式場景的特點是授權(quán)驗證時只需要client_id和redirect_uri這兩個參數(shù)作應(yīng)用標識，返回的時候也就直接在uri片段中返回access token衰粹。那就是只要合作方網(wǎng)站锣光、平臺方網(wǎng)站甚至是瀏覽器三者之一有任何一個xss笆怠，就很容易通過xss獲取到access token铝耻，然后以此攻擊受害者的平臺方賬號。

解決方案：

解決這個問題蹬刷，rfc6749第10.16小節(jié)就只是語焉不詳?shù)恼f需要額外的安全措施瓢捉，這也反映了這種場景的防御難處。
有一種方案办成，平臺方必須對應(yīng)用方的應(yīng)用強制進行分類泡态，即應(yīng)用方在申請client_id（即應(yīng)用appkey）時，需要選擇屬于哪類應(yīng)用迂卢；平臺方再根據(jù)分類開放對應(yīng)權(quán)限某弦，并且進行特定的防御和監(jiān)控措施。

4.1.3 安全漏洞回顧之密碼模式（授權(quán)流程參照前面的介紹）

wooyun案例：

• 2012-11-05 WooYun: 開心網(wǎng)android客戶端暴力破解漏洞而克，測試2000帳號靶壮，成功132個

  
  
  
  

  解決方案：

（1）對于外部合作方，最大限度取消且不?使用密碼授權(quán)的授權(quán)员萍。對于因為合同原因而導(dǎo)致無法取消的情況腾降，需要加強監(jiān)控。
（2）內(nèi)部應(yīng)用一樣要劃分等級碎绎，無必要的應(yīng)用一律禁止使用密碼授權(quán)模式螃壤。

資源提供方:
　　對client_id和回調(diào)地址做嚴格校驗
　　獲取access token的code僅能使用一次，且與授權(quán)用戶關(guān)聯(lián)
　　盡量避免直接讀取當(dāng)前用戶session進行綁定
　　有效使用client_secret參數(shù)
資源使用方:
　　使用Authorization Code方式進行授權(quán)
　　授權(quán)過程使用state隨機哈希,并在服務(wù)端進行判斷
　　盡量使用HTTPS保證授權(quán)過程的安全性
最后筋帖，對oauth2.0有詳細的了解奸晴，嚴格按照流程進行開發(fā)。

參考資料：
　　官方文檔：https://tools.ietf.org/html/rfc6749
　　說說oauth那點事：http://www.reibang.com/p/b06944c92228
　　OAuth 2.0安全案例回顧：http://www.cnblogs.com/maoxiaolv/p/5832996.html