什么是OAuth2.0

OAuth（Open Authorization）是一個(gè)關(guān)于授權(quán)（authorization）的開(kāi)放網(wǎng)絡(luò)標(biāo)準(zhǔn)，允許用戶授權(quán)第三方應(yīng)用訪問(wèn)他們存儲(chǔ)在另外的服務(wù)提供者上的信息，而不需要將用戶名和密碼提供給第三方移動(dòng)應(yīng)用或分享他們數(shù)據(jù)的所有內(nèi)容。OAuth在全世界得到廣泛應(yīng)用，目前的版本是2.0版

用戶可以通過(guò)選擇其他登錄方式來(lái)使用gitee，這里就使用到了第三方認(rèn)證。

來(lái)自RFC 6749

OAuth 引入了一個(gè)授權(quán)層，用來(lái)分離兩種不同的角色：客戶端和資源所有者?！Y源所有者同意以后，資源服務(wù)器可以向客戶端頒發(fā)令牌。客戶端通過(guò)令牌，去請(qǐng)求數(shù)據(jù)。

為什么要使用OAuth2.0

在OAuth之前，HTTP Basic Authentication, 即用戶輸入用戶名，密碼的形式進(jìn)行驗(yàn)證, 這種形式是不安全的。OAuth的出現(xiàn)就是為了解決訪問(wèn)資源的安全性以及靈活性。OAuth使得第三方應(yīng)用對(duì)資源的訪問(wèn)更加安全。

小靜現(xiàn)在想要將手機(jī)云中的相冊(cè)美照，放置到QQ空間中展示，按照傳統(tǒng)方式小靜要怎么做呢？

• 將照片從“手機(jī)云”中download下來(lái)，在上傳到“QQ空間相冊(cè)”展示。
• 下載/上傳太麻煩了，小靜可以直接把“云相冊(cè)”的賬號(hào)和密碼告訴“QQ空間”，由“QQ空間”下載照片在上傳。

對(duì)于上面的兩種方法，方法一太麻煩但是相對(duì)于小靜來(lái)說(shuō)是安全的；方法二對(duì)于小靜是比較方便，但是將賬號(hào)密碼告訴了“QQ空間”就相當(dāng)于把所有的“手機(jī)云”資料交給了它，這肯定是不可取的。

所以，為了解決類似上面的問(wèn)題，Oauth協(xié)議誕生了。

OAuth2.0協(xié)議流程

應(yīng)用場(chǎng)景

• 原生app授權(quán)：app登錄請(qǐng)求后臺(tái)接口，為了安全認(rèn)證，所有請(qǐng)求都帶token信息，如果登錄驗(yàn)證、 請(qǐng)求后臺(tái)數(shù)據(jù)。
• 前后端分離單頁(yè)面應(yīng)用：前后端分離框架，前端請(qǐng)求后臺(tái)數(shù)據(jù)，需要進(jìn)行oauth2安全認(rèn)證
• 第三方應(yīng)用授權(quán)登錄，比如QQ，微博，微信的授權(quán)登錄。

步驟解讀：

第1步：瀏覽器打開(kāi)Gitee碼云，點(diǎn)擊微信方式授權(quán)登錄，重定向到微信授權(quán)服務(wù)頁(yè)面等待獲取授權(quán)碼；

第2步：用戶打開(kāi)手機(jī)登錄微信掃描“二維碼”，點(diǎn)擊“允許”授權(quán)，將重定向到客戶端（Gitee）應(yīng)用提供的URI；

第3步：客戶端（Gitee）使用上一步獲取的授權(quán)碼，向微信授權(quán)服務(wù)器申請(qǐng)令牌（Token）；

第4步：微信授權(quán)服務(wù)器對(duì)客戶端（Gitee）進(jìn)行認(rèn)證以后，確認(rèn)無(wú)誤，同意發(fā)放令牌；

第5步：客戶端使用令牌向資源服務(wù)器（微信）申請(qǐng)獲取資源；

第6步：資源服務(wù)器（微信）確認(rèn)令牌無(wú)誤后，同意向客戶端開(kāi)放資源；

角色

• Third-party application：第三方應(yīng)用程序，又稱"客戶端"（client），即例子中的"Gitee"。
• HTTP service：HTTP服務(wù)提供商，簡(jiǎn)稱"服務(wù)提供商"，即例子中的微信。
• Resource Owner：資源所有者，又稱"用戶"，也就是你（user）。
• User Agent：用戶代理，比如瀏覽器。
• Authorization server：授權(quán)服務(wù)器，即服務(wù)提供商專門用來(lái)處理認(rèn)證授權(quán)的服務(wù)器。
• Resource server：資源服務(wù)器，即服務(wù)提供商存放用戶生成的資源的服務(wù)器。它與授權(quán)服務(wù)器，可以是同一臺(tái)服務(wù)器，也可以是不同的服務(wù)器。

OAuth的作用就是讓"客戶端"安全可控地獲取"用戶"的授權(quán)，與"服務(wù)提供商"進(jìn)行交互。

認(rèn)證流程

（A）用戶打開(kāi)客戶端以后，客戶端要求用戶給予授權(quán)。

（B）用戶同意給予客戶端授權(quán)。

（C）客戶端使用上一步獲得的授權(quán)，向認(rèn)證服務(wù)器申請(qǐng)令牌。

（D）認(rèn)證服務(wù)器對(duì)客戶端進(jìn)行認(rèn)證以后，確認(rèn)無(wú)誤，同意發(fā)放令牌。

（E）客戶端使用令牌，向資源服務(wù)器申請(qǐng)獲取資源。

（F）資源服務(wù)器確認(rèn)令牌無(wú)誤，同意向客戶端開(kāi)放資源。

上面六個(gè)步驟之中，B是關(guān)鍵，即用戶怎樣才能給于客戶端授權(quán)。有了這個(gè)授權(quán)以后，客戶端就可以獲取令牌，進(jìn)而憑令牌獲取資源。

令牌的特點(diǎn)

• 令牌又時(shí)效性，一般是短期的，且不能修改，密碼一般是長(zhǎng)期有效的
• 令牌可以由頒發(fā)者撤銷，且即時(shí)生效，密碼一般可以不用修改而長(zhǎng)期有效
• 令牌可以設(shè)定權(quán)限的范圍，且使用者無(wú)法修改

在使用令牌時(shí)需要保證令牌的保密，令牌驗(yàn)證有效即可進(jìn)入系統(tǒng)，不會(huì)再做其他的驗(yàn)證。

OAuth2.0授權(quán)模式

客戶端必須得到用戶的授權(quán)（authorization grant），才能獲得令牌（access token）。OAuth 2.0一共分成四種授權(quán)類型（authorization grant）

• 授權(quán)碼模式（authorization code）
• 簡(jiǎn)化模式（implicit）
• 密碼模式（resource owner password credentials）
• 客戶端模式（client credentials）

授權(quán)碼模式和密碼模式比較常用。

授權(quán)碼模式

授權(quán)碼（authorization code）方式，指的是第三方應(yīng)用先申請(qǐng)一個(gè)授權(quán)碼，然后再用該碼獲取令牌。

這種方式是最常用的流程，安全性也最高，它適用于那些有后端的 Web 應(yīng)用。授權(quán)碼通過(guò)前端傳送，令牌則是儲(chǔ)存在后端，而且所有與資源服務(wù)器的通信都在后端完成。這樣的前后端分離，可以避免令牌泄漏。

適用場(chǎng)景：目前主流的第三方驗(yàn)證都是采用這種模式

主要流程：

（A）用戶訪問(wèn)客戶端，后者將前者導(dǎo)向授權(quán)服務(wù)器。

（B）用戶選擇是否給予客戶端授權(quán)。

（C）用戶給予授權(quán)，授權(quán)服務(wù)器將用戶導(dǎo)向客戶端事先指定的"重定向URI"（redirection URI），同時(shí)附上一個(gè)授權(quán)碼。

（D）客戶端收到授權(quán)碼，附上早先的"重定向URI"，向授權(quán)服務(wù)器申請(qǐng)令牌。這一步是在客戶端的后臺(tái)的服務(wù)器上完成的，對(duì)用戶不可見(jiàn)。

（E）授權(quán)服務(wù)器核對(duì)了授權(quán)碼和重定向URI，確認(rèn)無(wú)誤后，向客戶端發(fā)送訪問(wèn)令牌（access token）和更新令牌（refresh token）。

請(qǐng)求示例：

• （A）步驟：客戶端申請(qǐng)認(rèn)證的URI

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

參數(shù)說(shuō)明：

參數(shù)類型	說(shuō)明
response_type	授權(quán)類型，必選項(xiàng)，此處的值固定為"code"
client_id	客戶端的ID，必選項(xiàng)
redirect_uri	重定向URI，認(rèn)證服務(wù)器接受請(qǐng)求之后的調(diào)轉(zhuǎn)連接，可以根據(jù)這個(gè)連接將生成的授權(quán)碼回傳，必選項(xiàng)
scope	code發(fā)送給資源服務(wù)器申請(qǐng)的權(quán)限范圍，可選項(xiàng)
state	任意值，認(rèn)證服務(wù)器會(huì)原樣返回,用于抵制CSRF(跨站請(qǐng)求偽造)攻擊。

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

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

參數(shù)說(shuō)明：

參數(shù)類型	說(shuō)明
code	授權(quán)碼，必選項(xiàng)。授權(quán)碼有效期通常設(shè)為10分鐘，一次性使用。該碼與客戶端ID、重定向URI以及用戶，是一一對(duì)應(yīng)關(guān)系。
state	原樣返回客戶端傳的該參數(shù)的值

• （D）步驟：客戶端向認(rèn)證服務(wù)器申請(qǐng)令牌

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

參數(shù)說(shuō)明：

參數(shù)類型	說(shuō)明
client_id	表示客戶端ID，必選項(xiàng)
client_secret	表示安全參數(shù)，只能在后端發(fā)請(qǐng)求
grant_type	表示使用的授權(quán)模式，必選項(xiàng)，此處的值固定為"authorization_code"
code	表示上一步獲得的授權(quán)碼，必選項(xiàng)
redirect_uri	表示重定向URI，必選項(xiàng)，且必須與A步驟中的該參數(shù)值保持一致

• （E）步驟：響應(yīng)（D）步驟的數(shù)據(jù)

{ "access_token":訪問(wèn)令牌, "token_type":"bearer", "expires_in":過(guò)期時(shí)間, "refresh_token":"REFRESH_TOKEN", "scope":"read", "uid":用戶ID,"info":{...} 
}

參數(shù)說(shuō)明：

參數(shù)類型	說(shuō)明
access_token	訪問(wèn)令牌，必選項(xiàng)
token_type	令牌類型，該值大小寫(xiě)不敏感，必選項(xiàng)
expires_in	過(guò)期時(shí)間，單位為秒。如果省略該參數(shù)，必須其他方式設(shè)置過(guò)期時(shí)間
refresh_token	更新令牌，用來(lái)獲取下一次的訪問(wèn)令牌，可選項(xiàng)
scope	權(quán)限范圍，如果與客戶端申請(qǐng)的范圍一致，此項(xiàng)可省略

**簡(jiǎn)化(隱式)**模式

有些 Web 應(yīng)用是純前端應(yīng)用，沒(méi)有后端。必須將令牌儲(chǔ)存在前端。RFC 6749 就規(guī)定了第二種方式，允許直接向前端頒發(fā)令牌，這種方式?jīng)]有授權(quán)碼這個(gè)中間步驟，所以稱為（授權(quán)碼）“隱藏式”（implicit）

簡(jiǎn)化模式不通過(guò)第三方應(yīng)用程序的服務(wù)器，直接在瀏覽器中向授權(quán)服務(wù)器申請(qǐng)令牌，跳過(guò)了"授權(quán)碼"這個(gè)步驟，所有步驟在瀏覽器中完成，令牌對(duì)訪問(wèn)者是可見(jiàn)的，且客戶端不需要認(rèn)證。

這種方式把令牌直接傳給前端，是很不安全的。因此，只能用于一些安全要求不高的場(chǎng)景，并且令牌的有效期必須非常短，通常就是會(huì)話期間（session）有效，瀏覽器關(guān)掉，令牌就失效了。

（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ā)給客戶端。

密碼模式

如果你高度信任某個(gè)應(yīng)用，RFC 6749 也允許用戶把用戶名和密碼，直接告訴該應(yīng)用。該應(yīng)用就使用你的密碼，申請(qǐng)令牌，這種方式稱為"密碼式"（password）。

在這種模式中，用戶必須把自己的密碼給客戶端，但是客戶端不得儲(chǔ)存密碼。這通常用在用戶對(duì)客戶端高度信任的情況下，比如客戶端是操作系統(tǒng)的一部分，或者由一個(gè)著名公司出品。而授權(quán)服務(wù)器只有在其他授權(quán)模式無(wú)法執(zhí)行的情況下，才能考慮使用這種模式。

適用場(chǎng)景：公司搭建的授權(quán)服務(wù)器

（A）用戶向客戶端提供用戶名和密碼。

（B）客戶端將用戶名和密碼發(fā)給認(rèn)證服務(wù)器，向后者請(qǐng)求令牌。

（C）認(rèn)證服務(wù)器確認(rèn)無(wú)誤后，向客戶端提供訪問(wèn)令牌。

客戶端模式

客戶端模式（Client Credentials Grant）指客戶端以自己的名義，而不是以用戶的名義，向"服務(wù)提供商"進(jìn)行 授權(quán)。

**適用于沒(méi)有前端的命令行應(yīng)用，即在命令行下請(qǐng)求令牌。**一般用來(lái)提供給我們完全信任的服務(wù)器端服務(wù)。

（A）客戶端向認(rèn)證服務(wù)器進(jìn)行身份認(rèn)證，并要求一個(gè)訪問(wèn)令牌。

（B）認(rèn)證服務(wù)器確認(rèn)無(wú)誤后，向客戶端提供訪問(wèn)令牌。