建站
咨詢
售后
建站咨詢
新聞中心
App 里用第三方登錄，在服務(wù)器端怎么做驗(yàn)證
OAuth2一般不適用公司內(nèi)部API調(diào)用，因?yàn)樗闹饕康氖墙鉀Q資源授權(quán)的問(wèn)題，而且OAuth2里面角色對(duì)于C/S結(jié)構(gòu)的app來(lái)說(shuō)太過(guò)于繁雜了，不太有必要折騰。
創(chuàng)新互聯(lián)長(zhǎng)期為上1000+客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為那曲企業(yè)提供專業(yè)的成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)，那曲網(wǎng)站改版等技術(shù)服務(wù)。擁有10年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。
移動(dòng)app比較簡(jiǎn)單的方法還是使用token（一種類似與httpcookie的東西），登錄之后得到token，任何請(qǐng)求都必須帶上它。因?yàn)槭莾?nèi)部賬戶體系，登錄也可以直接使用用戶名密碼，驗(yàn)證成功服務(wù)器就返回token，沒(méi)有必要做各種code/token交換的事情。
不過(guò)如果公司資源變得非常獨(dú)立和分離了，OAuth2還是很有價(jià)值的。部門公司，為了讓公司內(nèi)部統(tǒng)一用戶名密碼，就實(shí)現(xiàn)了一個(gè)基本的OAuth2流程，負(fù)責(zé)給各種內(nèi)網(wǎng)網(wǎng)站授權(quán)，確實(shí)比較方便。
OAuth2.0的四種授權(quán)模式，你會(huì)了嗎？
OAuth（開放授權(quán)）是一個(gè)開放標(biāo)準(zhǔn)，允許用戶授權(quán)第三方移動(dòng)應(yīng)用訪問(wèn)他們存儲(chǔ)在另外的服務(wù)提供者上的信息，而不需要將用戶名和密碼提供給第三方移動(dòng)應(yīng)用或分享他們數(shù)據(jù)的所有內(nèi)容，OAuth2.0是OAuth協(xié)議的延續(xù)版本，但不向后兼容OAuth
1.0即完全廢止了OAuth1.0。
第三方應(yīng)用授權(quán)登錄：在APP或者網(wǎng)頁(yè)接入一些第三方應(yīng)用時(shí)，時(shí)長(zhǎng)會(huì)需要用戶登錄另一個(gè)合作平臺(tái)，比如QQ，微博，微信的授權(quán)登錄。
原生app授權(quán)：app登錄請(qǐng)求后臺(tái)接口，為了安全認(rèn)證，所有請(qǐng)求都帶token信息，如果登錄驗(yàn)證、請(qǐng)求后臺(tái)數(shù)據(jù)。
前后端分離單頁(yè)面應(yīng)用（spa）：前后端分離框架，前端請(qǐng)求后臺(tái)數(shù)據(jù)，需要進(jìn)行oauth2安全認(rèn)證，比如使用vue、react后者h(yuǎn)5開發(fā)的app。
3.名詞定義
（1） Third-party application：第三方應(yīng)用程序，本文中又稱"客戶端"（client），比如打開知乎，使用第三方登錄，選擇qq登錄，這時(shí)候知乎就是客戶端。
（2）HTTP service：HTTP服務(wù)提供商，本文中簡(jiǎn)稱"服務(wù)提供商"，即上例的qq。
（3）Resource Owner：資源所有者，本文中又稱"用戶"（user）,即登錄用戶。
（4）User Agent：用戶代理，本文中就是指瀏覽器。
（5）Authorization server：認(rèn)證服務(wù)器，即服務(wù)提供商專門用來(lái)處理認(rèn)證的服務(wù)器。
（6）Resource server：資源服務(wù)器，即服務(wù)提供商存放用戶生成的資源的服務(wù)器。它與認(rèn)證服務(wù)器，可以是同一臺(tái)服務(wù)器，也可以是不同的服務(wù)器。
第一步：用戶訪問(wèn)頁(yè)面時(shí)，重定向到認(rèn)證服務(wù)器。
第二步：認(rèn)證服務(wù)器給用戶一個(gè)認(rèn)證頁(yè)面，等待用戶授權(quán)。
第三步：用戶授權(quán)，認(rèn)證服務(wù)器想應(yīng)用頁(yè)面返回Token
第四步：驗(yàn)證Token，訪問(wèn)真正的資源頁(yè)面
第一步：用戶訪問(wèn)頁(yè)面
第二步：訪問(wèn)的頁(yè)面將請(qǐng)求重定向到認(rèn)證服務(wù)器
第三步：認(rèn)證服務(wù)器向用戶展示授權(quán)頁(yè)面，等待用戶授權(quán)
第四步：用戶授權(quán)，認(rèn)證服務(wù)器生成一個(gè)code和帶上client_id發(fā)送給應(yīng)用服務(wù)器 然后，應(yīng)用服務(wù)器拿到code，并用client_id去后臺(tái)查詢對(duì)應(yīng)的client_secret
第五步：將code、client_id、client_secret傳給認(rèn)證服務(wù)器換取access_token和? refresh_token
第六步：將access_token和refresh_token傳給應(yīng)用服務(wù)器
第七步：驗(yàn)證token，訪問(wèn)真正的資源頁(yè)面
第一步：用戶訪問(wèn)用頁(yè)面時(shí)，輸入第三方認(rèn)證所需要的信息(QQ/微信賬號(hào)密碼)
第二步：應(yīng)用頁(yè)面那種這個(gè)信息去認(rèn)證服務(wù)器授權(quán)
第三步：認(rèn)證服務(wù)器授權(quán)通過(guò)，拿到token，訪問(wèn)真正的資源頁(yè)面
優(yōu)點(diǎn)：不需要多次請(qǐng)求轉(zhuǎn)發(fā)，額外開銷，同時(shí)可以獲取更多的用戶信息。(都拿到賬號(hào)密碼了)
缺點(diǎn)：局限性，認(rèn)證服務(wù)器和應(yīng)用方必須有超高的信賴。(比如親兄弟？)
應(yīng)用場(chǎng)景：自家公司搭建的認(rèn)證服務(wù)器
第一步：用戶訪問(wèn)應(yīng)用客戶端
第二步：通過(guò)客戶端定義的驗(yàn)證方法，拿到token，無(wú)需授權(quán)
第三步：訪問(wèn)資源服務(wù)器A
第四步：拿到一次token就可以暢通無(wú)阻的訪問(wèn)其他的資源頁(yè)面。
這是一種最簡(jiǎn)單的模式，只要client請(qǐng)求，我們就將AccessToken發(fā)送給它。這種模式是最方便但最不安全的模式。因此這就要求我們對(duì)client完全的信任，而client本身也是安全的。
因此這種模式一般用來(lái)提供給我們完全信任的服務(wù)器端服務(wù)。在這個(gè)過(guò)程中不需要用戶的參與。
OAuth2 授權(quán)
引自balckheart大神的博文
通俗的話可以這樣去理解，假如你們公司正在開發(fā)一個(gè) 第三方應(yīng)用XXX ，該應(yīng)用會(huì)需要在 微信 中分享出來(lái)一個(gè)活動(dòng)頁(yè)，該活動(dòng)需要讓 微信用戶 去參與，你們的應(yīng)用需要 收集到用戶的姓名，頭像，地域 等信息，那么問(wèn)題來(lái)了？你的應(yīng)用如何才能拿到所有參與活動(dòng)的微信用戶的基本信息呢?
根據(jù)以上示例，可以將OAuth2分為四個(gè)角色：
不難看出，OAuht2 解決問(wèn)題的關(guān)鍵在于使用 授權(quán)服務(wù)器 提供一個(gè) 訪問(wèn)憑據(jù) 給到 第三方應(yīng)用 ，讓 第三方應(yīng)用 可以在 不知道資源所有者 在 資源服務(wù)器上的賬號(hào)和密碼 的情況下，能獲取到 資源所有者 在 資源服務(wù)器 上的 受保護(hù)資源 ，這里的受保護(hù)資源就是 微信用戶的姓名以及頭像等信息 。
引用 blackheart 博主 的流程圖
拿上述的獲取微信用戶信息示例來(lái)說(shuō)
至此，整套授權(quán)流程結(jié)束，可以看出 訪問(wèn)令牌 是整個(gè)流程中的核心
除此之外，還需要提供一個(gè)讓第三方應(yīng)用程序注冊(cè)的管理后臺(tái)，當(dāng)?shù)谌綉?yīng)用注冊(cè)后會(huì)給到第三方應(yīng)用一個(gè)app_id app_secret ，app_secret是第三方應(yīng)用程序的私鑰，不允許在授權(quán)過(guò)程中傳遞的，主要用戶安全加密用。
引用 blackheart 博主 的流程圖
簡(jiǎn)要闡述一下各步驟
第三方應(yīng)用使用用戶代理（瀏覽器，或自己的服務(wù)器）訪問(wèn)微信授權(quán)服務(wù)器提供的一個(gè)url，該url就是提供獲取授權(quán)碼的url，第三方應(yīng)用需要傳遞一下參數(shù)
示例請(qǐng)求
微信授權(quán)服務(wù)器驗(yàn)證第三方應(yīng)用再上一步中傳遞的參數(shù)，確認(rèn)無(wú)誤后會(huì)提供一個(gè)頁(yè)面給微信用戶a登錄或者手動(dòng)確認(rèn)授權(quán)操作，操作超過(guò)后微信授權(quán)服務(wù)器會(huì)根據(jù)redirect_uri重定向到該地址，并攜帶下發(fā)的授權(quán)許可code
類似重定向地址
第三方應(yīng)用根據(jù)上一步拿到的授權(quán)碼code以及app_id，重定向地址等參數(shù)，再次請(qǐng)求微信授權(quán)服務(wù)器，請(qǐng)求獲取訪問(wèn)令牌access_token
請(qǐng)求示例如下
微信授權(quán)服務(wù)器返回訪問(wèn)令牌和一些刷新令牌，令牌過(guò)期時(shí)間等信息給到第三方應(yīng)用
返回示例如下：
第三方應(yīng)用根據(jù)訪問(wèn)令牌去微信資源服務(wù)器獲取微信用戶a的基本信息。
請(qǐng)求參數(shù)示例
請(qǐng)求url示例
返回參數(shù)示例
返回url示例
請(qǐng)求參數(shù)示例
請(qǐng)求url 示例
請(qǐng)求參數(shù)示例
當(dāng)訪問(wèn)令牌過(guò)期時(shí)，由第三方應(yīng)用調(diào)用微信授權(quán)服務(wù)器的刷新令牌接口，傳遞以下參數(shù)即可。
這樣就可以一直使用有效的訪問(wèn)令牌啦
OAuth 2.0 授權(quán)認(rèn)證詳解
一、認(rèn)識(shí) OAuth 2.0
1.1 OAuth 2.0 應(yīng)用場(chǎng)景
OAuth 2.0 標(biāo)準(zhǔn)目前被廣泛應(yīng)用在第三方登錄場(chǎng)景中，以下是虛擬出來(lái)的角色，闡述 OAuth2 能幫我們干什么，引用阮一峰這篇理解OAuth 2.0中的例子：
有一個(gè)"云沖印"的網(wǎng)站，可以將用戶儲(chǔ)存在Google的照片，沖印出來(lái)。用戶為了使用該服務(wù)，必須讓"云沖印"讀取自己儲(chǔ)存在Google上的照片。
問(wèn)題是只有得到用戶的授權(quán)，Google才會(huì)同意"云沖印"讀取這些照片。那么，"云沖印"怎樣獲得用戶的授權(quán)呢？
傳統(tǒng)方法是，用戶將自己的Google用戶名和密碼，告訴"云沖印"，后者就可以讀取用戶的照片了。這樣的做法有以下幾個(gè)嚴(yán)重的缺點(diǎn)。
1.2 名詞概念
OAuth 就是為了解決上面這些問(wèn)題而誕生的。在詳解 OAuth 之前，需要明確一些基本的概念，從上面場(chǎng)景中抽象出以下概念。
第三方應(yīng)用程序
Third-party application ：第三方應(yīng)用程序，本文中又稱"客戶端"（client），即上一節(jié)例子中的"云沖印"。
HTTP服務(wù)提供商
HTTP service ：HTTP服務(wù)提供商，本文中簡(jiǎn)稱"服務(wù)提供商"，即上一節(jié)例子中的Google。
資源所有者
Resource Owner ：資源所有者，本文中又稱"用戶"（user）。
用戶代理
User Agent ：用戶代理，本文中就是指瀏覽器。
認(rèn)證服務(wù)器
Authorization server ：認(rèn)證服務(wù)器，即服務(wù)提供商專門用來(lái)處理認(rèn)證的服務(wù)器。
資源服務(wù)器
Resource server ：資源服務(wù)器，即服務(wù)提供商存放用戶生成的資源的服務(wù)器。它與認(rèn)證服務(wù)器，可以是同一臺(tái)服務(wù)器，也可以是不同的服務(wù)器。
知道了上面這些名詞，就不難理解，OAuth的作用就是讓"客戶端"安全可控地獲取"用戶"的授權(quán)，從而可以和"服務(wù)商提供商"進(jìn)行互動(dòng)。
二、OAuth 的授權(quán)認(rèn)證流程
2.1 認(rèn)證思路
OAuth 在"客戶端"與"服務(wù)提供商"之間，設(shè)置了一個(gè) 授權(quán)層 （authorization layer）。"客戶端"不能直接登錄"服務(wù)提供商"，只能登錄授權(quán)層，以此將用戶與客戶端區(qū)分開來(lái)。"客戶端"登錄授權(quán)層所用的令牌（token），與用戶的密碼不同。用戶可以在登錄的時(shí)候，指定授權(quán)層令牌的權(quán)限范圍和有效期。
"客戶端"登錄授權(quán)層以后，"服務(wù)提供商"根據(jù)令牌的權(quán)限范圍和有效期，向"客戶端"開放用戶儲(chǔ)存的資料。
2.2 認(rèn)證流程
官方 RFC 6749 文件中的 OAuth 2.0 流程圖有點(diǎn)晦澀，優(yōu)化了 一下：
上述中的第 2 步 是關(guān)鍵，即用戶怎樣才能給于客戶端授權(quán)。有了這個(gè)授權(quán)以后，客戶端就可以獲取令牌，進(jìn)而憑令牌獲取資源。
三、四種授權(quán)模式
上一小節(jié)可以得出用戶對(duì)客戶端的授權(quán)動(dòng)作是核心，客戶端必須得到用戶的授權(quán)（authorization grant），才能獲得令牌（access token）。OAuth 2.0定義了四種授權(quán)方式：
3.1 授權(quán)碼模式（authorization code）
授權(quán)碼（authorization code）方式，指的是第三方應(yīng)用先申請(qǐng)一個(gè)授權(quán)碼，然后再用該碼獲取令牌。
3.2 簡(jiǎn)化模式（implicit）
有些 Web 應(yīng)用是純前端應(yīng)用，沒(méi)有后端。這時(shí)就不能用上面的方式了，必須將令牌儲(chǔ)存在前端。RFC 6749 就規(guī)定了第二種方式，允許直接向前端頒發(fā)令牌。這種方式?jīng)]有授權(quán)碼這個(gè)中間步驟，所以稱為（授權(quán)碼）"隱藏式"（implicit）。
3.3 密碼模式（resource owner password credentials）
如果你高度信任某個(gè)應(yīng)用，RFC 6749 也允許用戶把用戶名和密碼，直接告訴該應(yīng)用。該應(yīng)用就使用你的密碼，申請(qǐng)令牌，這種方式稱為"密碼式"（password）。
3.4 客戶端模式（client credentials）
最后一種方式是憑證式（client credentials），適用于沒(méi)有前端的命令行應(yīng)用，即在命令行下請(qǐng)求令牌。
四、授權(quán)碼模式詳解
4.1 授權(quán)碼模式流程
授權(quán)碼模式（authorization code）是功能最完整、流程最嚴(yán)密安全的授權(quán)模式。它的特點(diǎn)就是通過(guò)客戶端的 后臺(tái)服務(wù)器 ，與"服務(wù)提供商"的認(rèn)證服務(wù)器進(jìn)行互動(dòng)。
注意這種方式適用于那些有后端的 Web 應(yīng)用。授權(quán)碼通過(guò)前端傳送，令牌則是儲(chǔ)存在后端，而且所有與資源服務(wù)器的通信都在后端完成。這樣的前后端分離，可以避免令牌泄漏。
授權(quán)碼模式流程如下：
從上述的流程描述可知，只有第 2 步需要用戶進(jìn)行授權(quán)操作，之后的流程都是在客戶端的后臺(tái)和認(rèn)證服務(wù)器后臺(tái)之前進(jìn)行"靜默"操作，對(duì)于用戶來(lái)說(shuō)是無(wú)感知的。
下面是上面這些步驟所需要的參數(shù)。
4.2 授權(quán)碼模式流程的五個(gè)步驟
第 1 步驟
參數(shù)說(shuō)明
第 1 步驟中，客戶端申請(qǐng)認(rèn)證的URI，包含以下參數(shù)：
示例
A 網(wǎng)站提供一個(gè)鏈接，用戶點(diǎn)擊后就會(huì)跳轉(zhuǎn)到 B 網(wǎng)站，授權(quán)用戶數(shù)據(jù)給 A 網(wǎng)站使用。下面就是 A 網(wǎng)站跳轉(zhuǎn) B 網(wǎng)站的一個(gè)示意鏈接：
上面 URL 中：
response_type參數(shù)表示要求返回授權(quán)碼（code）；
client_id參數(shù)讓 B 網(wǎng)站知道是誰(shuí)在請(qǐng)求；
redirect_uri參數(shù)是 B 網(wǎng)站接受或拒絕請(qǐng)求后的跳轉(zhuǎn)網(wǎng)址；
scope參數(shù)表示要求的授權(quán)范圍（這里是只讀）。
第 2 步驟
第 2 步驟中，用戶跳轉(zhuǎn)后，B 網(wǎng)站會(huì)要求用戶登錄，然后詢問(wèn)是否同意給予 A 網(wǎng)站授權(quán)。
第 3 步驟
參數(shù)說(shuō)明
第 3 步驟中，服務(wù)器回應(yīng)客戶端的URI，包含以下參數(shù)：
示例
在第 2 步驟用戶表示同意之后，這時(shí) B 網(wǎng)站就會(huì)跳回redirect_uri參數(shù)指定的網(wǎng)址。跳轉(zhuǎn)時(shí)，會(huì)傳回一個(gè)授權(quán)碼，就像下面這樣。
上面 URL 中，code參數(shù)就是授權(quán)碼。
第 4 步驟
參數(shù)說(shuō)明
第 4 步驟中，客戶端向認(rèn)證服務(wù)器申請(qǐng)令牌的HTTP請(qǐng)求，包含以下參數(shù)：
示例
在第 3 步驟中，A 網(wǎng)站拿到授權(quán)碼以后，就可以在后端，向 B 網(wǎng)站請(qǐng)求令牌。
上面 URL 中：
client_id參數(shù)和client_secret參數(shù)用來(lái)讓 B 確認(rèn) A 的身份（client_secret參數(shù)是保密的，因此只能在后端發(fā)請(qǐng)求）；
grant_type參數(shù)的值是AUTHORIZATION_CODE，表示采用的授權(quán)方式是授權(quán)碼；
code參數(shù)是上一步拿到的授權(quán)碼；
redirect_uri參數(shù)是令牌頒發(fā)后的回調(diào)網(wǎng)址。
第 5 步驟
參數(shù)說(shuō)明
第 5 步驟中，認(rèn)證服務(wù)器發(fā)送的HTTP回復(fù)，包含以下參數(shù)：
示例
第 4 步驟中，B 網(wǎng)站收到請(qǐng)求以后，就會(huì)頒發(fā)令牌。具體做法是向redirect_uri指定的網(wǎng)址，發(fā)送一段 JSON 數(shù)據(jù)：
上面 JSON 數(shù)據(jù)中，access_token字段就是令牌，A 網(wǎng)站在后端拿到了。注意：HTTP頭信息中明確指定不得緩存。
五、令牌（Token）傳遞方式
當(dāng)客戶端（第三方應(yīng)用程序）拿到訪問(wèn)資源服務(wù)器的令牌時(shí)，便可以使用這個(gè)令牌進(jìn)行資源訪問(wèn)了。
在第三方應(yīng)用程序拿到access_token后，如何發(fā)送給資源服務(wù)器這個(gè)問(wèn)題并沒(méi)有在 RFC6729 文件中定義，而是作為一個(gè)單獨(dú)的 RFC6750 文件中獨(dú)立定義了。這里做以下簡(jiǎn)單的介紹，主要有三種方式如下：
5.1 請(qǐng)求頭參數(shù)傳遞
Authorization Request Header Field，因?yàn)樵贖TTP應(yīng)用層協(xié)議中，專門有定義一個(gè)授權(quán)使用的Request Header，所以也可以使用這種方式：
其中"Bearer "是固定的在access_token前面的頭部信息。
5.2 表單編碼傳遞
使用 Request Body 這種方式，有一個(gè)額外的要求，就是 Request Header 的Content-Type必須是固定的application/x-www-form-urlencoded，此外還有一個(gè)限制就是 不可以使用 GET 訪問(wèn)，這個(gè)好理解，畢竟 GET 請(qǐng)求是不能攜帶 Request Body 的。
5.3 URI 請(qǐng)求參數(shù)傳遞
URI Query Parameter，這種使用途徑應(yīng)該是最常見的一種方式，非常簡(jiǎn)單，比如：
在我們請(qǐng)求受保護(hù)的資源的 Url 后面追加一個(gè) access_token 的參數(shù)即可。另外還有一點(diǎn)要求，就是 Client 需要設(shè)置以下 Request Header 的 Cache-Control:no-store ，用來(lái)阻止 access_token 不會(huì)被 Web 中間件給 log 下來(lái)，屬于安全防護(hù)方面的一個(gè)考慮。
5.4 令牌的刷新
為了防止客戶端使用一個(gè)令牌無(wú)限次數(shù)使用，令牌一般會(huì)有過(guò)期時(shí)間限制，當(dāng)快要到期時(shí)，需要重新獲取令牌，如果再重新走授權(quán)碼的授權(quán)流程，對(duì)用戶體驗(yàn)非常不好，于是 OAuth 2.0 允許用戶自動(dòng)更新令牌。
具體方法是，B 網(wǎng)站頒發(fā)令牌的時(shí)候，一次性頒發(fā)兩個(gè)令牌，一個(gè)用于獲取數(shù)據(jù)，另一個(gè)用于獲取新的令牌（refresh token 字段）。令牌到期前，用戶使用 refresh token 發(fā)一個(gè)請(qǐng)求，去更新令牌。
上面 URL 中：
grant_type參數(shù)為refresh_token表示要求更新令牌，此處的值固定為refresh_token，必選項(xiàng)；
client_id參數(shù)和client_secret參數(shù)用于確認(rèn)身份；
refresh_token參數(shù)就是用于更新令牌的令牌。
B 網(wǎng)站驗(yàn)證通過(guò)以后，就會(huì)頒發(fā)新的令牌。
注意： 第三方應(yīng)用服務(wù)器拿到刷新令牌必須存于服務(wù)器，通過(guò)后臺(tái)進(jìn)行重新獲取新的令牌，以保障刷新令牌的保密性。
六、OAuth2的安全問(wèn)題
6.1 CSRF攻擊
應(yīng)用程序在早期使用 OAuth2 的時(shí)候爆發(fā)過(guò)不少相關(guān)的安全方面的漏洞，其實(shí)仔細(xì)分析后會(huì)發(fā)現(xiàn)大都都是沒(méi)有嚴(yán)格遵循 OAuth2 的安全相關(guān)的指導(dǎo)造成的，相關(guān)的漏洞事件自行搜索。
其實(shí) OAuth2 在設(shè)計(jì)之初是已經(jīng)做了很多安全方面的考慮，并且在 RFC6749 中加入了一些安全方面的規(guī)范指導(dǎo)。比如：
安全無(wú)小事，這方面是要靠各方面（開放平臺(tái)，第三方開發(fā)者）共同防范的。
6.2 攻擊流程
假設(shè)有用戶張三，攻擊者李四，第三方"云沖印"應(yīng)用（它集成了第三方社交賬號(hào)登錄，并且允許用戶將社交賬號(hào)和"云沖印"中的賬號(hào)進(jìn)行綁定），以及 OAuth2 服務(wù)提供者 Google。
步驟1
攻擊者李四登錄"云沖印"網(wǎng)站，并且選擇綁定自己的 Google 賬號(hào)
步驟2
"云沖印"網(wǎng)站將李四重定向到 Google，由于他之前已經(jīng)登錄過(guò) Google，所以 Google 直接向他顯示是否授權(quán)"云沖印"訪問(wèn)的頁(yè)面。
步驟3
李四在點(diǎn)擊"同意授權(quán)"之后，截獲 Google 服務(wù)器返回的含有Authorization code參數(shù)的HTTP響應(yīng)。
步驟4
李四精心構(gòu)造一個(gè) Web 頁(yè)面，它會(huì)觸發(fā)"云沖印"網(wǎng)站向 Google 發(fā)起令牌申請(qǐng)的請(qǐng)求，而這個(gè)請(qǐng)求中的Authorization Code參數(shù)正是上一步截獲到的 code。
步驟5
李四將這個(gè) Web 頁(yè)面放到互聯(lián)網(wǎng)上，等待或者誘騙受害者張三來(lái)訪問(wèn)。
步驟6
張三之前登錄了"云沖印"網(wǎng)站，只是沒(méi)有把自己的賬號(hào)和其他社交賬號(hào)綁定起來(lái)。在張三訪問(wèn)了李四準(zhǔn)備的這個(gè) Web 頁(yè)面，令牌申請(qǐng)流程在張三的瀏覽器里被順利觸發(fā)，"云沖印"網(wǎng)站從 Google 那里獲取到access_token，但是這個(gè) token 以及通過(guò)它進(jìn)一步獲取到的用戶信息卻都是攻擊者李四的。
步驟7
"云沖印"網(wǎng)站將李四的 Google 賬號(hào)同張三的"云沖印"賬號(hào)關(guān)聯(lián)綁定起來(lái)，從此以后，李四就可以用自己的 Google 賬號(hào)通過(guò) OAuth 登錄到張三在 "云沖印" 網(wǎng)站中的賬號(hào)，堂而皇之的冒充張三的身份執(zhí)行各種操作。
從整體上來(lái)看，本次 CSRF 攻擊的時(shí)序圖應(yīng)該是下面這個(gè)樣子的：
從上圖中可以看出，造成 CSRF 攻擊漏洞問(wèn)題的關(guān)鍵點(diǎn)在于，OAuth2 的認(rèn)證流程是分為好幾步來(lái)完成的，在上一章節(jié)授權(quán)碼模式流程中的流程圖中的第 4步驟中，第三方應(yīng)用在收到一個(gè) GET 請(qǐng)求時(shí)，除了能知道當(dāng)前用戶的 cookie，以及 URL 中的Authorization Code之外，難以分辨出這個(gè)請(qǐng)求到底是用戶本人的意愿，還是攻擊者利用用戶的身份偽造出來(lái)的請(qǐng)求。
于是，攻擊者就能使用移花接木的手段，提前準(zhǔn)備一個(gè)含有自己的Authorization Code的請(qǐng)求，并讓受害者的瀏覽器來(lái)接著完成后續(xù)的令牌申請(qǐng)流程。
6.3 解決方案
要防止這樣的攻擊其實(shí)很容易，作為第三方應(yīng)用的開發(fā)者，只需在 OAuth 認(rèn)證過(guò)程中加入state參數(shù)，并驗(yàn)證它的參數(shù)值即可。具體細(xì)節(jié)如下：
state參數(shù)在 OAuth2 認(rèn)證過(guò)程中不是必選參數(shù)，因此在早期第三方應(yīng)用開發(fā)者在集成 OAuth2 認(rèn)證的時(shí)候很容易會(huì)忽略它的存在，導(dǎo)致應(yīng)用易受 CSRF 攻擊。所以必須對(duì)這個(gè)安全問(wèn)題重視起來(lái)。
安全是雙方的，需要第三方應(yīng)用和資源服務(wù)提供商均要嚴(yán)格遵守安全規(guī)范。如 QQ 互聯(lián)的 OAuth2 API 中，state 參數(shù)是強(qiáng)制必選的參數(shù)，授權(quán)接口是基于 HTTPS 的加密通道等；作為第三方開發(fā)者在使用消費(fèi)這些服務(wù)的時(shí)候也應(yīng)該重視注意安全中存在的漏洞。
標(biāo)題名稱：App與服務(wù)器端接口安全oauth2 app與服務(wù)器對(duì)接
URL標(biāo)題：http://www.dlmjj.cn/article/dopdssh.html
