OAuth2.0是一個(gè)開(kāi)放授權(quán)協(xié)議仅仆，或者理解為一個(gè)標(biāo)準(zhǔn)入篮，在全世界得到廣泛應(yīng)用，目前版本是2.0拯腮；OAuth一共有兩個(gè)版本窖式，2007年12月發(fā)布了1.0版本，2010年4月發(fā)布了2.0版本动壤，由于1.0版本存在嚴(yán)重的安全漏洞萝喘，而在2.0版本中解決了該問(wèn)題。并在2012年10月琼懊，OAuth 2.0協(xié)議正式發(fā)布為RFC 6749（中文翻譯）阁簸。
1. 模擬一個(gè)OAuth2.0的應(yīng)用場(chǎng)景
有一個(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)。
"云沖印"為了后續(xù)的服務(wù)伊滋，會(huì)保存用戶的密碼碳却，這樣很不安全。
Google不得不部署密碼登錄笑旺，而我們知道昼浦，單純的密碼登錄并不安全。
"云沖印"擁有了獲取用戶儲(chǔ)存在Google所有資料的權(quán)力筒主，用戶沒(méi)法限制"云沖印"獲得授權(quán)的范圍和有效期关噪。
用戶只有修改密碼，才能收回賦予"云沖印"的權(quán)力乌妙。但是這樣做使兔，會(huì)使得其他所有獲得用戶授權(quán)的第三方應(yīng)用程序全部失效。
只要有一個(gè)第三方應(yīng)用程序被破解藤韵，就會(huì)導(dǎo)致用戶密碼泄漏虐沥，以及所有被密碼保護(hù)的數(shù)據(jù)泄漏。
OAuth就是為了解決上面這些問(wèn)題而誕生的泽艘。
2. OAuth2.0角色的聲明
OAuth定義了四種角色：
1）資源所有者
能夠許可對(duì)受保護(hù)資源的訪問(wèn)權(quán)限的實(shí)體欲险。當(dāng)資源所有者是個(gè)人時(shí)，它被稱為最終用戶匹涮。（上述場(chǎng)景中代指“用戶”）
2）資源服務(wù)器
托管受保護(hù)資源的服務(wù)器天试，能夠接收和響應(yīng)使用訪問(wèn)令牌對(duì)受保護(hù)資源的請(qǐng)求。
3）客戶端
使用資源所有者的授權(quán) 代表資源所有者發(fā)起對(duì)受保護(hù)資源的請(qǐng)求的應(yīng)用程序然低。術(shù)語(yǔ)“客戶端”并非特指任何特定的的實(shí)現(xiàn)特點(diǎn)（例如：應(yīng)用程序是否是在服務(wù)器喜每、臺(tái)式機(jī)或其他設(shè)備上執(zhí)行）。上述場(chǎng)景代指“云沖印”雳攘。
4）授權(quán)服務(wù)器
在成功驗(yàn)證資源所有者且獲得授權(quán)后頒發(fā)訪問(wèn)令牌給客戶端的服務(wù)器带兜。
授權(quán)服務(wù)器和資源服務(wù)器之間的交互超出了本規(guī)范的范圍。授權(quán)服務(wù)器可以和資源服務(wù)器是同一臺(tái)服務(wù)器吨灭，也可以是分離的個(gè)體鞋真。一個(gè)授權(quán)服務(wù)器可以頒發(fā)被多個(gè)資源服務(wù)器接受的訪問(wèn)令牌。
3. OAuth解決思路
OAuth在"客戶端"與"服務(wù)提供商"之間沃于，設(shè)置了一個(gè)授權(quán)層（authorization layer）涩咖。"客戶端"不能直接登錄"服務(wù)提供商"海诲，只能登錄授權(quán)層，以此將用戶與客戶端區(qū)分開(kāi)來(lái)檩互。"客戶端"登錄授權(quán)層所用的令牌（token）特幔，與用戶的密碼不同。用戶可以在登錄的時(shí)候闸昨，指定授權(quán)層令牌的權(quán)限范圍和有效期蚯斯。
"客戶端"登錄授權(quán)層以后，"服務(wù)提供商"根據(jù)令牌的權(quán)限范圍和有效期饵较，向"客戶端"開(kāi)放用戶儲(chǔ)存的資料拍嵌。
4. OAuth2.0開(kāi)放授權(quán)協(xié)議流程
協(xié)議流程圖描述了四種角色之間的交互，包括一下步驟（最重要的是B步驟循诉，即用戶如何給客戶端進(jìn)行授權(quán)）：
- A）客戶端從資源所有者處請(qǐng)求授權(quán)横辆。授權(quán)請(qǐng)求可以直接向資源所有者發(fā)起（如圖所示），或者更可取的是通過(guò)授權(quán)服務(wù)器作為中介間接發(fā)起
- B）客戶端收到授權(quán)許可茄猫，這是一個(gè)代表資源所有者的授權(quán)的憑據(jù)狈蚤，使用本規(guī)范中定義的四種許可類型之一或者使用擴(kuò)展許可類型表示。授權(quán)許可類型取決于客戶端請(qǐng)求授權(quán)所使用的方法以及授權(quán)服務(wù)器支持的類型划纽。
- C）客戶端與授權(quán)服務(wù)器進(jìn)行身份認(rèn)證并出示授權(quán)許可以請(qǐng)求訪問(wèn)令牌脆侮。
- D）授權(quán)服務(wù)器驗(yàn)證客戶端身份并驗(yàn)證授權(quán)許可，若有效則頒發(fā)訪問(wèn)令牌勇劣。
- E）客戶端從資源服務(wù)器請(qǐng)求受保護(hù)資源并出示訪問(wèn)令牌進(jìn)行身份驗(yàn)證靖避。
- F）資源服務(wù)器驗(yàn)證訪問(wèn)令牌，若有效則處理該請(qǐng)求比默。
5. 授權(quán)許可類型
1）授權(quán)碼
授權(quán)碼通過(guò)使用授權(quán)服務(wù)器做為客戶端與資源所有者的中介而獲得幻捏。客戶端不是直接從資源所有者請(qǐng)求授權(quán)退敦，而是引導(dǎo)資源所有者至授權(quán)服務(wù)器（由在RFC2616中定義的用戶代理）粘咖，授權(quán)服務(wù)器之后引導(dǎo)資源所有者帶著授權(quán)碼回到客戶端蚣抗。
在引導(dǎo)資源所有者攜帶授權(quán)碼返回客戶端前侈百，授權(quán)服務(wù)器會(huì)鑒定資源所有者身份并獲得其授權(quán)。由于資源所有者只與授權(quán)服務(wù)器進(jìn)行身份驗(yàn)證翰铡，所以資源所有者的憑據(jù)不需要與客戶端分享钝域。
它的步驟如下：（這個(gè)圖添加了用戶代理角色，一般可認(rèn)為是瀏覽器提供這個(gè)角色）
（A）用戶訪問(wèn)客戶端锭魔，后者將前者導(dǎo)向認(rèn)證服務(wù)器例证。
（B）用戶選擇是否給予客戶端授權(quán)。
（C）假設(shè)用戶給予授權(quán)迷捧，認(rèn)證服務(wù)器將用戶導(dǎo)向客戶端事先指定的"重定向URI"（redirection URI）织咧，同時(shí)附上一個(gè)授權(quán)碼胀葱。
（D）客戶端收到授權(quán)碼，附上早先的"重定向URI"笙蒙，向認(rèn)證服務(wù)器申請(qǐng)令牌抵屿。這一步是在客戶端的后臺(tái)的服務(wù)器上完成的，對(duì)用戶不可見(jiàn)捅位。
（E）認(rèn)證服務(wù)器核對(duì)了授權(quán)碼和重定向URI轧葛，確認(rèn)無(wú)誤后，向客戶端發(fā)送訪問(wèn)令牌（access token）和更新令牌（refresh token）艇搀。
2）隱式授權(quán)
該方式不通過(guò)第三方應(yīng)用程序的服務(wù)器尿扯，直接在瀏覽器中向認(rèn)證服務(wù)器申請(qǐng)令牌，跳過(guò)了"授權(quán)碼"這個(gè)步驟焰雕，因此得名衷笋。所有步驟在瀏覽器中完成，令牌對(duì)訪問(wèn)者是可見(jiàn)的淀散，且客戶端不需要認(rèn)證右莱。
隱式許可是為用如JavaScript等腳本語(yǔ)言在瀏覽器中實(shí)現(xiàn)的客戶端而優(yōu)化的一種簡(jiǎn)化的授權(quán)碼流程。在隱式許可流程中档插，不再給客戶端頒發(fā)授權(quán)碼慢蜓，取而代之的是客戶端直接被頒發(fā)一個(gè)訪問(wèn)令牌（作為資源所有者的授權(quán)）。這種許可類型是隱式的郭膛，因?yàn)闆](méi)有中間憑據(jù)（如授權(quán)碼）被頒發(fā)（之后用于獲取訪問(wèn)令牌）晨抡。
當(dāng)在隱式許可流程中頒發(fā)訪問(wèn)令牌時(shí)，發(fā)授權(quán)服務(wù)器不對(duì)客戶端進(jìn)行身份驗(yàn)證则剃。在某些情況下耘柱，客戶端身份可以通過(guò)用于向客戶端傳送訪問(wèn)令牌的重定向URI驗(yàn)證。訪問(wèn)令牌可能會(huì)暴露給資源所有者棍现，或者對(duì)資源所有者的用戶代理有訪問(wèn)權(quán)限的其他應(yīng)用程序调煎。
它的步驟如下：
（A）客戶端將用戶導(dǎo)向認(rèn)證服務(wù)器。
（B）用戶決定是否給于客戶端授權(quán)己肮。
（C）假設(shè)用戶給予授權(quán)士袄，認(rèn)證服務(wù)器將用戶導(dǎo)向客戶端指定的"重定向URI"，并在URI的Hash部分包含了訪問(wèn)令牌谎僻。
（D）瀏覽器向資源服務(wù)器發(fā)出請(qǐng)求娄柳，其中不包括上一步收到的Hash值。
（E）資源服務(wù)器返回一個(gè)網(wǎng)頁(yè)艘绍，其中包含的代碼可以獲取Hash值中的令牌赤拒。
（F）瀏覽器執(zhí)行上一步獲得的腳本，提取出令牌。
（G）瀏覽器將令牌發(fā)給客戶端挎挖。
3）密碼模式
密碼模式（Resource Owner Password Credentials Grant）中这敬，用戶向客戶端提供自己的用戶名和密碼〗抖洌客戶端使用這些信息鹅颊，向"服務(wù)商提供商"索要授權(quán)。
在這種模式中墓造，用戶必須把自己的密碼給客戶端堪伍，但是客戶端不得儲(chǔ)存密碼。這通常用在用戶對(duì)客戶端高度信任的情況下觅闽，比如客戶端是操作系統(tǒng)的一部分帝雇，或者由一個(gè)著名公司出品。而認(rèn)證服務(wù)器只有在其他授權(quán)模式無(wú)法執(zhí)行的情況下蛉拙，才能考慮使用這種模式尸闸。
它的步驟如下：
（A）用戶向客戶端提供用戶名和密碼。
（B）客戶端將用戶名和密碼發(fā)給認(rèn)證服務(wù)器孕锄，向后者請(qǐng)求令牌吮廉。
（C）認(rèn)證服務(wù)器確認(rèn)無(wú)誤后，向客戶端提供訪問(wèn)令牌畸肆。
4）客戶端授權(quán)
客戶端模式（Client Credentials Grant）指客戶端以自己的名義宦芦，而不是以用戶的名義，向"服務(wù)提供商"進(jìn)行認(rèn)證轴脐。嚴(yán)格地說(shuō)调卑，客戶端模式并不屬于OAuth框架所要解決的問(wèn)題。在這種模式中大咱，用戶直接向客戶端注冊(cè)恬涧，客戶端以自己的名義要求"服務(wù)提供商"提供服務(wù)，其實(shí)不存在授權(quán)問(wèn)題碴巾。
它的步驟如下：
（A）客戶端向認(rèn)證服務(wù)器進(jìn)行身份認(rèn)證欺抗，并要求一個(gè)訪問(wèn)令牌。
（B）認(rèn)證服務(wù)器確認(rèn)無(wú)誤后强重，向客戶端提供訪問(wèn)令牌绞呈。
參考文章：
